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The  Institute  for  Defense  Analyses  is  a  non-profit  corporation  that  operates 
three  federally  funded  research  and  development  centers  to  provide  objective 
analyses  of  national  security  issues,  particularly  those  requiring  scientific  and 
technical  expertise,  and  conduct  related  research  on  other  national  challenges. 
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Executive  Summary 


Background 

The  DoD  enterprise  is  a  unique  business  model.  Its  annual  budget  is  equal  to  the  17th  largest 
economy  in  the  world.  Its  size,  diversity  of  many  interconnected  businesses,  and  a  mission  that 
requires  its  personnel  to  train  and  fight  and  offer  humanitarian  assistance  anywhere  in  the  world 
on  an  immediate  and  contingency  basis  make  finding  a  comparable  business  model  in  industry 
impossible.  The  Department’s  business  of  achieving  its  missions  equates  to  an  economy  more 
than  a  commercial  business. 

Designed  to  transfonn  business  operations,  Enterprise  Resource  Planning  (ERP)  systems  are 
enabling  technologies  composed  of  integrated  modules  that  make  up  the  core  engine  of 
transaction  processing.  Their  effectiveness  depends  on  the  ability  and  willingness  of  an 
organization  to  change  its  behavior  and  its  processes.  These  principles  and  success  factors  have 
been  learned  over  the  past  20  years,  as  commercial-off-the-shelf  (COTS)  software  has  become 
the  primary  enabler  for  meeting  business  transfonnation  expectations. 

The  Study 

DoD  has  identified  key  systems  that  are  essential  to  its  efforts  to  transfonn  business  operations. 
As  of  December  2009,  DoD  had  invested  over  $5.8  billion  in  ERPs  and  will  invest  additional 
billions  before  the  ERPs  are  fully  implemented.  Most  of  these  programs  are  over  budget,  behind 
schedule,  and  have  not  met  performance  expectations.  The  House  Armed  Services  Committee 
(HASC)  “directed  the  Secretary  of  Defense  to  have  an  outside  company  or  other  entity  conduct 
an  independent  analysis  of  DoD  financial  IT  systems  and  submit  the  findings  to  the 
congressional  defense  committees  within  180  days  after  the  date  of  the  enactment  of  this  Act. 
This  assessment  should  detennine  if  there  are  overlaps  in  capabilities  currently  in  development, 
and  how  well  these  programs  are  able  to  adhere  to  cost  and  schedule.  This  assessment  should 
include  service  programs,  as  well  as  any  program  being  developed  by  the  defense  agencies.1”  In 
response  to  this  request,  the  DoD  tasked  the  Institute  for  Defense  Analyses  (IDA)  to:  (1) 
determine  the  status  of  the  ERPs,  (2)  investigate  capability  overlaps,  (3)  analyze  cost  and 
schedule  overruns;  and  (4)  provide  recommendations  on  the  DoD  business  system  investment 
strategy  and  propose  possible  corrective  action. 


1  U.S.  Congress.  House  of  Representatives.  Committee  on  Armed  Services.  National  Defense  Authorization  Act  for 
Fiscal  Year  2010.  1 1 1th  Cong.,  2010. 
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Senior  Defense  leaders  are  increasingly  aware  that  the  economic  environment  demands  that  the 
DoD  move  from  “defense  readiness  at  any  cost”  to  “defense  readiness  at  the  best  value.”  While 
DoD  sees  the  potential  of  ERPs  to  lead  to  a  clean  financial  audit,  the  issues  affecting  successful 
fielding  of  IT  capabilities  and  a  clean  financial  audit  go  beyond  system  acquisition.  Therefore, 
this  comprehensive  study  addresses  aspects  of  policy,  organization,  training,  personnel,  and 
leadership.  During  the  study,  the  following  questions  were  considered  from  the  enterprise, 
operational,  and  financial/transactional  viewpoints: 

•  What  is  the  level  of  congruency  organizationally  and  financially  between  the  DoD 
enterprise  and  large  commercial  firms  with  like  global  footprints? 

•  What  has  to  happen  for  the  current  ERPs  to  be  successful  components  of  the  overall  IT 
investment  strategy? 

•  To  what  degree  is  there  overlap  in  capabilities,  and  is  there  benefit  to  some  redundancy  in 
capabilities? 

•  How  do  current  policy  (e.g.,  the  Chief  Financial  Officers  Act  of  1990'  (CFO  Act)), 
briefings,  and  audits  affect  programs? 

•  To  what  degree  should  the  voice  of  the  users  prevail  when  making  decisions  about 
operational  systems? 

•  To  what  degree  is  DoD  realizing  the  full  capabilities  of  ERP  investments  made  at  service 
components  and  Other  Defense  Agencies  (ODA)? 

•  What  progress  has  been  made  towards  achieving  a  clean  audit  opinion? 

•  As  a  result  of  investments  to  date  in  DoD,  what  general  progress  has  been  made  towards 
more  streamlined  and  efficient  operations? 

Principal  Findings 

IDA  is  not  confident  that  DoD’s  current  ERP  implementation  strategy  will  deliver  the  expected 
capabilities  on  time  and  within  budget. 

At  the  DoD  enterprise  level  apparent  capability  overlaps  reflect  different  capabilities  at  the 
operational  or  transactional  level  to  support  specific  business  operations  and  missions  of  the 
Department.  At  the  Service  and  Agency  overlapping  missions  could  equate  to  capability  overlap, 
but  consolidating  these  capability  overlaps  into  the  DoD  enterprise  could  break  the  overall 
business  process  within  a  Service  or  Agency. 

There  is  confusion  about  the  connection  between  ERPs  and  auditability.  The  Services  are  using 
ERPs  as  the  primary  enabler  for  business  modernization  and  financial  improvement.  They  expect 
ERPs  to  provide  enforcement  of  referential  integrity  across  all  dependent  data  elements, 
transactional  traceability,  visibility  of  key  information  (budget  execution,  assets),  improved 


2  Pub.  L.  No.  101-576,  104  Stat.  2838  (November  15,  1990). 
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operational  controls  and  cost  accounting,  minimal  manual  intervention  for  reconciliation,  and 
seamless  business  process  execution  across  and  between  functional  stovepipes.  However,  this  is 
not  the  way  the  systems  are  being  implemented. 

Incentives  to  achieve  expectations  are  not  aligned  with  how  DoD  budgets  and  allocates  resources 
to  programs.  For  instance,  a  program  manager  with  the  courage  to  recommend  changing  a 
program’s  course  (e.g.,  pausing,  streamlining,  or  cancelling  a  program)  must  continue  to  meet 
cost  and  schedule  thresholds  or  funding  will  be  lost.  A  program  manager  who  is  forthcoming  is 
not  necessarily  rewarded. 

The  commercial  business  goals  of  making  a  profit,  remaining  solvent,  and  limiting  risk/liability, 
and  the  implicit  tax  strategies  (valuation  and  depreciation)  are  inconsistent  with  the  DoD 
business  model.  DoD  and  its  components  have  a  higher  congruency  with  “Defense  as  an 
economy”  rather  than  “Defense  as  a  Commercial  Business”  which  has  profound  implications 
regarding  the  value  of  comprehensive  commercial-style  financial  statements.  Because  the  federal 
government  answers  to  taxpayers,  not  shareholders,  as  its  primary  stakeholders,  the  existence 
and  completeness  of  DoD  assets  are  important  business  indicators  AND  valuable  to  DoD 
operations.  A  cost  accounting  approach  would  be  more  meaningful  to  DoD. 

The  Department’s  new  Chief  Management  Officer  (CMO)  construct  for  business  operations  may 
provide  the  top-level  support  needed  to  break  through  the  organizational  friction  points  caused 
by  the  functional  stovepipes  in  the  DoD  enterprise.  DoD  has  made  progress  in  many  business 
areas,  including  improper  payments,  instituting  internal  controls,  and  vendor  compliance. 
However,  consistent  and  sustainable  enterprise-wide  gains  must  still  be  achieved. 

Principal  Recommendations 

DoD  and  Congress  need  to  assess  the  DoD  business  model  ,  gain  an  appreciation  of  how  it 
differs  from  a  corporate  business  model,  and  apply  the  appropriate  information  technology 
solution(s)  for  the  DoD  business  model.  Furthermore,  the  financial  representation  of  DoD’s 
business  must  take  into  account  these  differences. 

DoD  should  stop  the  pursuit  of  comprehensive  financial  statement  audits.  Instead,  audit  readiness 
with  a  specific  focus  on  the  Statement  of  Budgetary  Resources  (SBR)  should  be  accomplished. 
Furthermore,  all  other  audit  readiness  activities  should  be  evaluated  as  to  their  operational  value 
before  resources  are  expended.  For  example,  asset  visibility,  existence,  and  completeness  are 
critically  important  from  compliance  and  operational  perspectives  and  are  therefore  high  value 
activities.  The  accounting  of  costs  should  be  the  primary  focus  of  the  Department. 

Where  there  is  no  significant  deployed  user  base  of  any  Service-level  ERP,  DoD  should  curtail 
the  deployment  of  the  ERP  in  FY12  and  beyond,  pending  a  thorough  review  of  the 
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Headquarters,  operational,  and  supporting  organizations  and  how  these  organizations  meet  the  objectives  of  a 
federal  defense  agency.  Understand  what  success  means  for  these  organizations. 
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organizational  environment  in  which  the  ERP  will  operate,  clear  definition  of  the  problem  the 
ERP  is  attempting  to  solve,  detennination  of  the  alignment  with  ERP  capabilities,  and 
development  of  an  implementable  data  strategy. 

DoD  should  define  a  way  forward  based  upon  solutions  at  a  level  in  the  organization  where  a 
single  accountable  leader  has  the  span  of  control  to  define,  implement,  and  execute  the  end-to- 
end  business  processes  the  IT  investment  is  intended  to  support.  In  doing  so,  DoD  should: 

•  Obtain  a  clear  understanding  of  today’s  business  problems  -  taking  into  account 
improvements  and  changes  (e.g.,  policy,  deployments  of  other  IT  investments)  that 
still  process  outside  the  ERP  program. 

•  Recognize  organizational  constraints — both  mission  and  political — and  demand 
verification  of  activities  that  are  geared  towards  high  perfonnance,  not  just  high 
compliance. 

•  Initiate  an  objective  assessment  of  what  the  ERP  programs  can  realistically  deliver. 

•  Create  an  open  environment  where  decisions  to  cancel  programs  have  incentives 
congruent  to  decisions  to  continue  programs.  When  a  program  manager 
recommends  changing  a  program’s  course  (e.g.,  pausing,  streamlining,  or 
cancelling  a  program),  program  leadership  should  consider  re-allocation  of  funds. 

•  Implement  IT  solutions  that  address  the  entire  Doctrine,  Organization,  Training, 
Materiel,  Leadership  and  Education,  Personnel  and  Facilities  (DOTMLPF) 
spectrum,  not  just  one  particular  component  at  the  expense  of  another. 

•  Establish  an  environment  beyond  leadership  and  demand  an  era  of  stewardship  as 
the  baseline  for  managing  the  Department’s  IT  investments.  That  is,  an  investment 
must  have  a  common  purpose  that  achieves  an  outcome  beyond  just  one 
department. 

All  oversight  and  reviews  of  MAIS  business  programs  should  be  coordinated  and  streamlined 
through  the  OSD  and  Military  Departments  (MilDep)  Deputy  CMOs  using  the  Investment 
Review  Boards  in  accordance  with  the  Business  Capability  Lifecycle4. 

•  The  MilDep  DCMOs  should  provide  the  business  portfolio  view  and  collective 
position  of  the  Service  to  the  OSD  DCMO.  The  MilDep  DCMOs  must  also  serve  as 
the  Chief  Collaboration  Officers  between  their  MilDep  and  sister  Services  to  ensure 
best  practices  are  leveraged  and  the  best  of  DoD’s  IT  investments  are  brought 
forward  for  the  benefit  of  the  whole  Department. 

•  The  MilDep  DCMOs  should  be  empowered  with  the  authority  and  responsibility  for 
establishing  the  strategy  and  execution  of  business  modernization  for  their 
Department.  This  should  include  the  systems  and  ancillary  resources  associated 
with  these  programs. 


4 


USD  (AT&L)  memo  of  15  Nov  2010,  Interim  Acquisition  Guidance  for  Defense  Business  Systems  (DBS). 
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1.  Introduction 


1.1  House  Committee  on  Armed  Services  (HASC)  Request 

The  House  Committee  on  Armed  Services  (HASC)  is  concerned  about  the  Department  of 
Defense’s  (DoD’s)  continued  lack  of  progress  in  implementing  sound  information  technology 
(IT)  systems  for  business  management  in  general,  and  financial  management  in  particular.  DoD 
systems  for  financial  and  contract  management  and  business  system  modernization  have  been  on 
the  Government  Accountability  Office  (GAO)  high-risk  list  for  nearly  fifteen  years.  As  long  as 
the  Department  lacks  effective  financial  management  systems,  it  will  not  be  able  to  achieve  the 
level  of  transparency  required  to  receive  a  clean  audit  opinion.  Implicit  is  the  expectation  that 
increasing  financial  transparency  and  moving  towards  an  unqualified  audit  opinion  will  allow  the 
Department  to  invest  additional  resources  in  higher  priorities. 

1.2  Background 

DoD  has  identified  key  Enterprise  Resource  Planning  ERP  systems,  as  essential  to  its  efforts  to 
transform  its  business  operations.  As  of  December  2009,  DoD  had  invested  over  $5.8  billion  in 
ERPs  and  will  invest  additional  billions  before  the  ERPs  are  fully  implemented.  Most  of  these 
programs  are  over  cost,  behind  schedule,  and/or  have  not  met  performance  expectations. 

•  Significant  changes  that  coincided  with  the  development  of  this  report  signaled  an 
increased  focus  on  fiscal  responsibility  including: 

•  In  early  August  2010,  Secretary  of  Defense  Robert  Gates  called  for  high  impact 
efficiencies  in  the  Department,  including  the  disestablishment  of  a  Combatant  Command 
(COCOM),  a  defense  agency,  and  an  OSD  organization. 

•  The  potential  competition  for  funding  had  expanded  beyond  the  traditional  DoD  weapon 
system  comparisons  to  include  health  care,  consumer  protection,  and  anticipated  energy 
initiatives. 

•  A  newly  formed  Debt  Commission  made  recommendations  indicating  that  all  debt 
reduction  options,  including  cuts  in  the  DoD’s  budget,  are  being  considered  as  a  way  to 
reduce  government  spending. 

•  Three  days  before  the  Debt  Commission  released  its  recommendations,  the  November 
2010  election  changed  leadership  in  the  House  of  Representatives. 
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1.3  The  Pursuit  of  a  Clean  Audit  Opinion 

Congress  has  made  several  attempts  in  legislation  (the  Chief  Financial  Officer  Act,  the 
Government  Perfonnance  and  Results  Act,  the  Clinger-Cohen  Act,  and  various  National  Defense 
Authorization  Acts)  to  improve  government  or  DoD  business  operations,  increase  perfonnance 
information  visibility,  and  achieve  clean  audit  opinions.  The  Ronald  W.  Reagan  National 
Defense  Authorization  Act  for  Fiscal  Year  2005s  directed  the  establishment  of  a  Business 
Enterprise  Architecture  (BEA),  “which  shall  be  sufficiently  defined  to  effectively  guide, 
constrain,  and  pennit  implementation  of  interoperable  defense  business  system  solutions  and 
consistent  with  the  policies  and  procedures  established  by  the  Director  of  the  Office  of 
Management  and  Budget.” 

In  2005  the  DoD  Comptroller  established  the  DoD  Financial  Improvement  and  Audit  Readiness 
(FIAR)  Plan  to  manage  DoD-wide  financial  improvement  efforts  and  to  integrate  those  efforts 
with  the  Department’s  enterprise  transformation  activities.  The  May  2010  FIAR  Plan  Status 
Report  states  that  the  Component  ERPs  are  “necessary”  to  obtain  and  sustain  an  unqualified 
opinion  on  their  Statement  of  Budgetary  Resources  (SBR),  which  is  the  current  focus  of  the  DoD 
Comptroller’s  auditability  efforts. 

DoD  has  identified  nine  ERP  systems  as  essential  to  transfonn  business  operations.  As  of 
December  2009,  DoD  had  invested  over  $5.8  billion  in  ERP  systems  and  will  invest  additional 
billions  before  the  ERPs  are  fully  implemented.  Most  of  these  programs  are  over  cost,  behind 
schedule,  and/or  have  not  met  perfonnance  expectations. 

1.4  Study  Scope 

Successful  fielding  of  complex  ERP  systems  and  the  attainment  of  a  clean  financial  audit 
requires  actions  that  go  well  beyond  acquisition  of  a  system.  Therefore,  this  study  takes  a 
comprehensive  perspective,  addressing  additional  aspects  of  Doctrine,  Organization,  Training, 
Materiel,  Leadership  and  Education  Personnel,  and  Facilities  (DOTMLPF).  During  the  study,  the 
following  questions  were  considered  from  the  enterprise,  operational,  and  financial/transactional 
viewpoints: 

•  What  is  the  level  of  congruency  organizationally  and  financially  between  the  DoD 
enterprise  and  large  commercial  firms  with  like  global  footprints? 

•  What  has  to  happen  for  the  current  ERPs  to  be  successful  components  of  the  overall  IT 
investment  strategy? 

•  To  what  degree  is  there  overlap  in  capabilities,  and  is  there  benefit  to  some  redundancy  in 
capabilities? 


5  Pub.  L.  108-375,  div.  A,  title  III,  §  332(c),  Oct.  28,  2004,  118  Stat.  1851. 
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•  How  do  current  policy  (e.g.,  the  Chief  Financial  Officers  Act  of  19906  (CFO  Act)), 
briefings,  and  audits  affect  programs? 

•  To  what  degree  should  the  voice  of  the  users  prevail  when  making  decisions  about 
operational  systems? 

•  To  what  degree  is  DoD  realizing  the  full  capabilities  of  ERP  investments  made  at  service 
components  and  Other  Defense  Agencies  (ODA)? 

•  What  progress  has  been  made  towards  achieving  a  clean  audit  opinion? 

•  As  a  result  of  investments  to  date  in  DoD,  what  general  progress  has  been  made  towards 
more  streamlined  and  efficient  operations? 

1.5  IDA’s  Role  and  Methodology 

In  its  report  on  the  National  Defense  Authorization  Act  for  Fiscal  Year  20107 8  (NDAA  2010),  the 
Committee  directed  the  Secretary  of  Defense  to  have  an  outside  company  or  other  entity  conduct 
an  independent  analysis  of  DoD  financial  IT  systems  and  submit  its  findings  within  180  days  of 
the  enactment  of  NDAA  2010.  The  HASC  launched  this  study  to  determine  the  status  of 
Enterprise  Resource  Planning  (ERP)  system  efforts,  to  investigate  capability  overlaps,  to  analyze 
cost  and  schedule  overruns,  and  to  provide  recommendations  and  possible  corrective  actions. 

Although  DoD  had  initiated  earlier  action  to  respond  to  the  Congressional  request,  further 
analysis  was  warranted  to  fully  satisfy  this  request.  As  a  result,  IDA  was  tasked  to  independently 
evaluate  the  progress  of  the  Department  with  regard  to: 

•  Realizing  the  full  capabilities  of  ERP  investments  at  service  components  and  Other 
Defense  Agencies  (ODA),  such  as  the  Defense  Logistics  Agency  (DLA); 

•  Progress  towards  achieving  a  clean  audit  opinion;  and 

•  General  progress  towards  a  more  streamlined  and  efficient  operations  as  a  result  of 
investments  made  to  date. 

To  accomplish  the  objectives  described  above,  IDA: 

1.  Identified,  collected,  and  reviewed  relevant  business  systems  documentation,  including 
DoD,  Service,  and  Defense  Agency  strategic  and  operational  policies  and  plans; 
acquisition-related  documentation;  financial  and  budget  data;  enterprise  and  program 
architectures;  external  studies  and  reports;  and  other  related  information. 

2.  Conducted  interviews  with  OSD,  Defense  Agency,  and  Service  senior  leadership  in 
acquisition,  budget,  and  finance,  military  department  Chief  Management  Officers 


6  Pub.  L.  No.  101-576,  104  Stat.  2838  (November  15,  1990). 

7  National  Defense  Authorization  Act  for  Fiscal  Year  2010,  Pub.  L.  1 1 1-84,  Oct.  28,  2009,  123  Stat.  2190. 

8  H.  Rept.  1 1 1-166,  p.  375,  June  18,  2009. 
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(CMOs),  and  program  management  personnel.  IDA  used  the  Assessment  Framework 
described  in  Appendix  G  to  facilitate  the  organization  of  the  information. 

3.  Reviewed  and  analyzed  historical  and  planned  cost  and  schedule  data,  capabilities, 
performance,  financial  and  budget  infonnation,  and  future  planning  for  major  ERPs, 
including  the  Navy  ERP,  Defense  Enterprise  Accounting  and  Management  System 
(DEAMS),  Expeditionary  Combat  Support  System  (ECSS),  General  Fund  Enterprise 
Business  System  (GFEBS),  Logistics  Modernization  Program  (LMP),  and  Defense 
Agency  Initiative  (DAI).  IDA  assessed  the  underlying  causes  of  cost  overruns,  the 
organizational  structure  used  for  ERP  strategic  and  operational  decision-making, 
acquisition-related  and  architectural  material,  including  the  Business  Enterprise 
Architecture  (BEA),  and  auditability  requirements  and  planning. 

4.  Analyzed  the  maturity  and  effectiveness  of  the  ERPs  and  ancillary  systems  implemented 
by  the  Air  Force,  Anny,  Navy,  Defense  Finance  and  Accounting  Service,  TRICARE  and 
Defense  Logistics  Agency. 

5.  Studied  the  ERP  implementations  of  some  companies  with  global  footprints. 

6.  Based  on  the  review  and  analysis  of  the  documentation,  interviews,  and  analysis, 
developed  findings,  conclusions,  and  recommendations  for  the  following  issue  areas 
relevant  to  the  assessment  of  ERP  implementation: 

•  Leadership,  Stewardship,  and  Governance 

•  Organizational  Alignment 

•  People  and  Culture 

•  Architecture,  Processes,  and  Systems 

•  Metrics 

Drawing  from  the  issue  area  analyses,  this  report  concludes  with  principal  conclusions  and 
rec  ommendations . 

The  specifics  of  the  analysis  found  in  the  appendices  were  the  basis  for  most  of  the  conclusions 
and  recommendations. 
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2.  ERP  Fundamentals  and  the  DoD  Approach 


The  findings  in  this  document  depend  upon  an  understanding  of  certain  key  principles  of 
application  software  implementation,  including  what,  at  a  minimum,  is  required  to  implement 
ERP  successfully  in  any  organization,  including  DoD.  These  principles  and  success  factors  have 
been  learned  over  the  past  20  years,  as  commercial-off-the-shelf  (COTS)  software  has  become 
the  primary  enabler  of  business  transformation  in  both  industry  and  the  Department. 

The  configuration  and  behavior  of  software  systems  reflect  existing  organizational  and  execution 
characteristics  and  constraints.  Software  systems  are  not  intrinsically  strategic;  ERP  is  an 
enabling  technology,  a  set  of  integrated  modules  that  make  up  the  core  engine  of  transaction 
processing.  An  ERP  cannot  and  should  not  be  used  as  a  forcing  function;  rather,  the  ability  and 
willingness  of  an  organization  to  change  its  behavior  and  its  processes  is  a  prerequisite  for 
successful  ERP  implementation. 

The  interviews  conducted  (See  Appendix  I)  confirmed  the  literature  regarding  the  critical  success 
factors  for  implementing  ERP  systems.  Successful  implementation  of  an  ERP,  meaning  that 
benefits  and  operational  improvements  are  realized  to  the  planned  extent,  is  contingent  upon 
such  fundamental  foundations  as: 

•  Sustained  involvement  of  senior  leadership  with  authority  over  and  accountability  for  the 
definition  and  execution  of  all  end-to-end  processes  impacted  by  the  ERP. 

•  Leadership  willingness  and  ability  to  make  hard  decisions  relative  to  proceeding  or  not 
proceeding  with  an  implementation  based  on  program  perfonnance. 

•  Strong  integrated  governance  that  includes  representation  of  and  participation  by  all 
impacted  stakeholders.  The  representatives  must  have  the  authority  to  make  decisions 
that  are  binding  on  the  communities  they  represent.  Decisions  must  be  made  rapidly  and 
the  effectiveness  of  the  governance  must  be  actively  measured  and  reported. 

•  An  organizational  operating  model  (structure  and  process)  aligned  to  the  design  of  the 
ERP  with  minimal  requirements  to  cross-organizational  boundaries  and  which  execute 
components  of  a  process  outside  of  the  ERP,  thus  breaking  the  inherent  integration  of  the 
ERP. 

•  A  strategy  and  approach  that  address  the  root  cause  (not  just  the  symptoms)  of  the 
problems  being  solved  and  the  measurable  operational  improvement  to  be  gained  by 
solving  them. 
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•  Personnel  with  the  requisite  skill  set  and  experience  necessary  to  define  and  execute  an 
ERP  implementation  (e.g.,  source  selection,  contracting,  vendor  management,  change 
management,  technical  oversight). 

•  Defined  metrics  for  operational  improvement  to  be  gained,  supported  by  a  baseline 
describing  existing  business  performance. 

•  Accurate,  consistent,  and  authoritative  data. 


To  succeed,  ERP  implementations  must  balance  these  fundamental  principles  and  foundations 
with  those  organizational  constraints  that  cannot  be  changed  and  the  constraints  of  the  design  of 
the  selected  ERP  software. 

2.1  DoD  Strategy  for  Business  Modernization  and  Financial  Improvement 

According  to  the  2010  FIAR  plan,  the  Department’s  financial  improvement  goal  is  to  become  an 
auditable  enterprise  by  focusing  on  improvements  to  business  and  financial  processes,  controls, 
systems,  and  data  to  achieve  accurate,  reliable,  and  timely  financial  information  for  decision 
makers,  validated  by  successful  financial  statement  audits. 

DoD’s  overarching  strategy  is  to  first  achieve  auditability  at  the  Component  level.  Specifically, 
the  individual  Component  financial  improvement  plans,  viewed  collectively,  comprise  the 
Department’s  FIAR  plan.  The  Service  and  Agency  ERPs  are  an  important  and  necessary 
component  of  their  current  approach  to  achieving,  obtaining,  and  sustaining  an  unqualified 
opinion  for  either  full  financial  statements  or  the  SBR. 

OSD  provides  the  focal  point  for  Business  Modernization  by  taking  DoD  enterprise  perspective 
and  using  the  only  organizational  construct  it  has  ownership  of — the  OSD  Principal  Staff 
Assistants  (PSAs)  who  lead  the  various  functional  stovepipes9  and  the  Deputy  Chief 
Management  Officer  (DCMO).  This  perspective  views  the  entire  department  as  a  single 
enterprise.  Within  that  view,  each  Service  and  Defense  Agency — and  possibly  other  components 
such  as  Combatant  Commands — are  also  seen  as  being  part  of  the  DoD  enterprise. 

ERP  software  typically  organizes  transactions  into  end-to-end  processes  across  multiple  business 
units  and  supporting  organizations  within  an  enterprise.  DoD  views  these  end-to-end  processes 
as  a  way  to  overcome  the  deleterious  effects  of  the  functional  stovepipes  by  describing  an 
enterprise  as  the  Service  or  Agency  implementing  the  ERP.  Typical  ERP  processes  include: 

•  Acquire-to-Retire 

•  Budget-to-Report 

•  Concept-to-Product 

•  Cost  Management 
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Non-operational  staff  roles  are  colloquially  described  within  DoD  as  functional  stovepipes. 
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•  Deployment-to-Redeployment/Retrograde 

•  Environmental  Liabilities 

•  Hire-to-Retire 

•  Market-to-Prospect 

•  Order-to-Cash 

•  Plan-to-Stock  -  Inventory  Management 

•  Procure-to-Pay 

•  Proposal-to-Reward 

•  Prospect-to-Order 

•  Service  Request-to-Resolution 

•  Service-to-Satisfaction 

Figure  1  illustrates  how  OSD  sees  the  end-to-end  processes,  Service  ERP  strategy,  and  OSD 
stovepipes  interrelating.  In  this  view,  the  Department  appears  to  be  a  single  enterprise  with 
uniform  processes  across  all  components.  The  whole  appears  simple  and  manageable.  The 
difficulty  is  that  while  transactions  happen  across  multiple  stovepipes,  each  stovepipe  (the  set  of 
processes  within  DoD  itself  or  within  a  Service  or  Defense  Agency)  controls  what  data  it  passes 
on  to  the  others — there  is  no  real  federation  across  multiple  ERP  implementations — without 
appropriate  attention  to  aligning  the  interfaces.  This  approach  cannot  produce  a  coherent  system 
across  the  DoD  enterprise. 


Objective  DoD  Systems  Environment 


Army 

rflttii 

Navy  USMC 


Air  Force 


EtE  Business  Process  &  ERP  Foundation 


EtE  Business  Process  &  ERP  Foundation 


EtE  Business  Process  &  ERP  Foundation 

dd  d  3  "3” 


EtE  Business  Process  &  ERP  Foundation 


USD  (AT&L)  USD  (P&R)  USD  (C)  ASD  (Nil) 


Disbursing 


DFAS 


EtE  =  End  to  End 
G/L  =  General  Ledger 


Figure  1.  DoD  Business  Mission  Area 
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Figure  2,  however,  shows  the  information  flows  more  realistically  and  demonstrates  that  no  one 
Service,  Agency,  or  even  OSD,  controls  the  end-to-end  processes.  To  meet  mission 
requirements,  given  the  organizational  structure  of  DoD,  business  information  often  travels 
across  multiple  organizational  boundaries  and  multiple  ERPs. 


Imaginary  Line 
Seldom  Crossed 


Business  Mission  Area  War  Fighter  Mission  Area 


Figure  2.  The  Complexity  of  DoD  Business  Information  Flows  -  Simplified 


As  an  example,  consider  the  end-to-end  process  for  Procure-to-Pay.  The  information  flows, 
systems,  and  organizations  involved  are  depicted  in  Figure  3.  DoD’s  strategy  has  the  core  ERPs 
allowing  other  organizational  systems  to  receive  and  take  control  of  the  data,  process  that  data, 
and  then  return  the  resulting  processed  data  back  to  the  originating  ERP. 
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Cross  Reference  Table 


PRPR  Line  Number/PR  Line  Funding  ID 
PO/PO  Line  Number/PO  Line  Funding  ID 
PIIN/CLIN/SLIN 

1  l  * 

•  Receipt  Validation  from  X-Ref 


PR 

PR  Line  Number 
PR  Line  Funding  ID 


PR  Line  Number  i 

PR  Line  Funding  ID  _  _Mateh  ^2™ 


•  PIIN  •  CLN  •  SLIN 

Contract  Writing  Contract  info  PIIN-CLIN-SLIN 


System 


Contract  info  PIIN-CLIN-SLIN 


MOCAS  System 
Contract  Admin 


Contract  info 
PIIN-CLIN-SLIN 


APM 

PPM 

Invoice  PIIN- 
CLIN-SLIN 

Disbursing 

(Prevalidation) 

(Prevalidation) 

System 

Invoice  PIIN-CLIN-SLIN 


Obligation 

Validation 


Disbursement 

PIIN-CLIN-SLIN 


MOCAS  System  Ready  to  Pay  File 

Entitlement  - 


WAWF 


Invoice  PIIN- 
CLIN-SLIN 

Material  PIIN-CLIN-SLIN 


•  Receipt  •  Report  •  PIIN  •  CLIN  •  SLIN 


Receipt  Validation  by  PIIN,  CLIN,  SLIN 


Material  PIIN-CLIN-SLIN 


The  Vendor 


Invoice  PIIN-CLIN-SLIN 


Activity 

Dependent 


Figure  3.  Procure  to  Pay 


If  a  Service  member  assigned  to  a  COCOM  places  an  order  for  some  materiel,  that  order  will  be 
placed  through  the  ERP  system  of  the  Service  that  is  the  Executive  Agent  for  the  COCOM  (the 
ordering  Service  member  may  or  may  not  belong  to  the  Executive  Agent  Service).  The  primary 
principle  underlying  DoD  financial  modernization  is  that  regardless  of  which  Service  receives  it, 
the  order  will  follow  the  process  in  Figure  3.  However,  because  each  Service  has  a  slightly 
different  process  for  Procure-to-Pay  (because  each  Service  has  a  different  mission,  culture, 
history,  etc.),  Figure  3  does  not  actually  depict  any  Service  process — and  it  also  does  not  show 
the  intersecting  end-to-end  processes  that  deliver  the  ordered  item.  It  is  probable  that  DLA, 
which  has  its  own  ERP  system,  will  provide  the  materiel  (which  means  it  will  have  been 
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procured  through  DLA  processes  that  differ  from  those  of  the  Executive  Agent  Service)  and 
USTRANSCOM  will  provide  some  or  all  of  the  transportation  for  the  order.  Some  of  that 
transportation  may  be  via  commercial  carriers  whose  services  were  procured  and  paid  for  using 
yet  another  ERP  system  and  another  somewhat  different  version  of  the  Procure-to-Pay  process. 
This  process  requires  an  understanding  that  the  end-to-end  processes  exist  in  the  War  Fighter 
Mission  Area  as  much  as  the  Business  Mission  Area;  thus  the  reference  to  crossing  the 
imaginary  line  in  Figure  2. 

2.2  Component  Strategies  for  Business  Modernization  and  Financial 
Improvement 

The  Services  and  Defense  Agencies  are  using  ERP  as  the  primary  enabler  for  business 
modernization  and  financial  improvement.  The  following  quotations  from  the  March  2010 
Congressional  Report  describe  their  views  of  how  they  are  using  ERP  to  meet  their  business 
transformation  goals: 

Army 

“The  Anny  is  on  an  incremental  path  to  an  integrated  architecture  and  interoperable  systems  for 
its  general  ledger  accounting  system  (GFEBS)  and  its  national  and  tactical  logistics  systems 
(LMP  and  GCSS-A10),  thus  giving  the  Army  improved  visibility  of  its  financial  and  logistics 
assets.  These  are  long-standing  priorities  for  Congress,  DoD  and  the  Army.” 

Navy 

“...[T]he  Navy  Enterprise  Resource  Planning  (ERP)  software,  a  key  steppingstone  to  naval 
operations  in  a  transformed  business  environment,  was  deployed  at  two  of  the  Navy’s  four  major 
acquisition  commands  (the  Naval  Air  Systems  Command  and  the  Naval  Supply  Center).  The 
major  acquisition  commands  are  the  largest  business  concerns  in  the  Navy.  When  fully 
implemented  across  the  systems  commands,  Navy  ERP  will  be  the  sole  financial  system 
managing  more  than  half  of  the  Navy’s  total  obligations.” 

Air  Force 

“...[T]he  Air  Force  has  worked  to  reduce  transactional  activities,  establish  transparent  processes 
and  consolidate  functions  while  providing  increased  capabilities  to  the  Warfighter.  This  is  being 
achieved  through  the  utilization  of  Enterprise  Resource  Planning  (ERP)  systems,  such  as  the 
Defense  Enterprise  Accounting  and  Management  System  (DEAMS)  and  Expeditionary  Combat 
Support  System  (ECSS).” 

DLA 
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Global  Combat  Support  System  -  Army 


10 


“DLA  currently  employs  its  Enterprise  Business  System  (EBS)  across  much  of  its  supply 
mission  area.  As  DLA’s  Enterprise  Resource  Planning  (ERP)  platform,  EBS  modernized  and 
refined  the  agency’s  ability  to  manage  the  supply  chain  effectively  and  efficiently.  EBS  uses  the 
ERP  approach  to  manage  seven  of  its  eight  supply  chains  and  facilitate  over  22,000  users 
operating  in  28  countries  worldwide.” 

The  Service  or  Agency,  associated  ERP  Program,  Vendor  selected  by  the  Agency,  and  the 
primary  focus  of  the  ERP  are  shown  in  the  Table  1. 

Table  1.  Major  Financial  and  Logistic  ERP  Systems  within  the  DoD 


Major  Financial  and  Logistic  ERP  Systems  within  DoD 

Service/Agency 

Program 

Vendor 

Primary  Focus 

Army 

GFEBS 

SAP 

Financial 

GCSS-Army 

SAP 

Logistics 

LMP 

SAP 

Logistics 

Navy 

Navy  ERP 

SAP 

Financial  and 

Logistics 

USMC 

GCSS-MC 

Oracle 

Logistics 

Air  Force 

ECSS 

Oracle 

Logistics 

DEAMS 

Oracle 

Financial 

DLA 

EBS 

SAP 

Logistics 

Other  Defense 

Agencies 

DAI 

Oracle 

Financial 

The  MilDep  and  Defense  Agencies  chose  to  use  ERP  systems  because  of  the  expectation  of  the 
benefits  such  as: 

•  Seamless  integration  across  and  between  functional  domains  and  business  processes  such 
as  “Procure-to-Pay”  and  “Acquire-to-Retire,”  which,  at  a  minimum,  cross  both  logistics 
and  financial  domains 

•  Enforcement  of  referential  integrity  across  all  dependent  data  elements 

•  Transaction  traceability  and  integrity 

•  Typical  business  processes  proven  across  thousands  of  implementations 

•  Visibility  of  key  information  required  for  the  effective  and  efficient  management  of  the 
enterprise  (For  example:  progress  of  budget  execution,  asset  visibility) 

•  Improved  operational  control  of  the  enterprise 

•  Best  practice  internal  controls 
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•  Cost  accounting  (which  does  not  consistently  exist  in  DoD) 

•  Minimal  manual  intervention  for  reconciliation 

2.3  Study  Structure 

The  following  sections  summarize  IDA’s  findings,  conclusions,  and  recommendations  relevant 
to  ERP  implementations  within  the  DOD  for  the  following  areas: 

•  Leadership,  Stewardship,  and  Governance 

•  Organizational  Alignment 

•  People  and  Culture 

•  Architecture,  Processes,  and  Systems 

•  Metrics 

Detailed  data,  analyses  and  other  supporting  information  are  contained  in  the  Appendices. 
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3.  Leadership,  Stewardship,  and  Governance 


Commander’s  Intent  and  a  Common  Purpose  are  essential  components  of  effective  leadership, 
stewardship  and  governance. 

3.1  Findings 

3.1.1  The  functional  governance  structures  at  both  the  DoD  and  Service  levels  are 
generally  ineffective. 

The  ERP  programs  of  the  Department  are  characterized  by  weaknesses  in  the  functional 
governance  structures  that  are  required  to  achieve  the  level  of  organizational  and  business 
process  change  as  well  as  maintain  the  discipline  required  to  avoid  customization  of  the  ERP  that 
drives  cost  and  schedule  growth. 

The  span  of  organizations  impacted  by  the  implementation  of  an  ERP  at  the  Service  enterprise 
level  requires  crossing  many  organizational  boundaries  within  the  Services  and  the  Department. 
In  most  cases,  the  implementing  functional  sponsor  who  chairs  the  senior  executive  body  is 
equal  or  lower  in  rank  than  the  owners  of  the  impacted  functional  domains  such  as  logistics  and 
human  resources,  or  the  commanders  of  impacted  top-level  operational  commands  (MAJCOMS, 
MACOMS,  ECHELON  II).  Governance  challenges  include  lack  of  empowerment  of  individuals 
at  lower  levels  to  make  decisions  that  are  binding  on  their  leadership  and  lack  of  metrics  to 
ensure  that  the  governance  processes  are  effective. 

3.1.2  Senior  leadership  must  have  authority  at  the  enterprise  level  for  business 
modernization  because  it  demands  implementation  and  accountability  of  enterprise- 
level  solutions. 

The  efforts  of  the  Department  to  achieve  auditability  are  typically  sponsored  by  the  person 
responsible  for  financial  management  in  each  of  the  Service  secretariats.  This  level  of 
sponsorship  would  be  appropriate  if  the  requirements  for  achieving  auditability  were  entirely 
under  the  control  of  a  senior  leader  at  this  level.  However,  to  achieve  auditability,  internal 
controls  must  be  addressed  within  the  non-financial  aspects  of  the  end-to-end  business  processes. 
An  example  is  the  requirement  for  controls  to  ensure  the  accuracy  of  depot  and  installation 
supply  inventories. 

Further,  the  Department’s  choice  to  use  ERP  systems  as  the  IT  enablers  in  support  of  these 
auditability  efforts  requires  that  all  aspects  of  the  end-to-end  business  process  be  part  of  the  same 
effort.  The  span  of  control  required  of  the  sponsor  is  well  beyond  that  of  the  leaders  of  the 
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financial  domains.  For  example,  many  of  the  business  and  financial  improvement  initiatives 
require  integration  and  engagement  across  and  between  the  Service  operational  commanders, 
Agencies,  and  COCOMs.  In  addition,  functions  such  as  contracting,  finance,  and  procurement  to 
global  distribution  and  combat  supply  are  included.  Therefore,  it  requires  a  sponsor  with  the 
authority  and  accountability  to  effect  the  required  business  change  across  many  organizations, 
stakeholders,  business  processes,  legacy  systems  and  data  sources  to  be  successful. 

This  implies  a  need  for  sponsorship  by  someone  at  or  above  the  level  of  Service  Under  Secretary 
of  Defense.  This  is  consistent  with  the  experience  of  industry  where  enterprise  ERP 
implementations  are  characterized  by  executive  sponsorship  from  the  Chief  Operating  Officer 
and  Chief  Technology  Officer.  These  positions  are  analogous  to  the  Service  Secretary  in 
authority. 

The  formal  roles  of  OSD  PSAs  and  Service  Secretariats  have  evolved  from  policy-making  and 
oversight  to  deep  involvement  in  defining  and  executing  detailed  processes.  This  change  began 
with  the  Financial  Management  Enterprise  Architecture  (FMEA)  program  but  became 
exacerbated  over  time  as  an  unintended  consequence  of  the  establishment  of  the  Business 
Transformation  Agency  (BTA). 

The  functional  community  has  decoupled  many  business  activities  from  mission  activities 
creating  stovepipes  rather  than  integrated  business  and  mission  processes.  This  evolution  stems 
from  the  need  for  specific  information  at  the  enterprise  and  HQ  levels  that  historically  has  not 
been  available,  accurate,  consistent,  timely,  nor,  in  many  cases,  trusted.  As  a  result  many  leaders 
believe  that,  in  order  to  obtain  and  trust  the  information,  they  had  to  have  a  hand  in  controlling 
the  source  of  the  data,  the  processes  that  produce  the  data,  and  the  systems  that  enable  it.  The 
overly  prescriptive  processes  contained  in  the  current  BEA  evidence  this.  Instead  of  focusing  on 
issuing  data  standards  in  support  of  enterprise  information  needs,  the  functional  communities 
have  chosen  to  meet  the  need  through  control  of  the  data  via  ownership  of  enterprise-level  ERP 
solutions.  As  a  result  of  this  ownership,  the  stovepipe  owner  is  now  dictating  the  details  of 
process  execution  across  all  of  the  operating  units  with  the  assumption  that  it  is  efficient  for  all 
units  to  do  business  exactly  the  same  way,  regardless  of  mission  and  the  authorities  of  the 
operational  commanders. 

3.2  Conclusions  and  Recommendations 

Top-down  leadership  without  substitution  of  subordinates  is  a  key  success  factor.  The  most 
senior  person  initiating  a  change  must  personally  champion  the  change.  If  the  key  leader  does  not 
have  the  time  or  the  will  to  follow  through  on  a  specific  commitment  and  obligation  made 
regarding  an  initiative  proclaimed  important,  then  the  initiative  should  be  abandoned.  This 
includes  oversight  bodies  such  as  the  Defense  Business  Systems  Management  Council 
(DBSMC)  and  Investment  Review  Boards  (IRB).  If  the  IRB  is  in  fact  the  decision-making  body, 
the  DBSMC  is  redundant;  there  seems  to  be  no  cross-functional  decision  maker.  Redundancies 
like  this  are  distractions  and  siphon  off  expensive  resources  for  no  gain  to  the  Department. 
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3.2.1  Multiple  and  redundant  governing  bodies  at  the  OSD  and  Service  levels  create  a 
lack  of  trust,  confusion,  lack  of  unity  of  effort,  increased  resource  requirements,  and 
distraction  from  execution. 

There  must  be  less  concern  for  individual  power.  Authorities  must  be  more  readily  combined 
among  DoD  leaders  towards  a  common  purpose  for  the  common  good  of  the  Department.  Trust 
of  people  and  the  need  for  open  collaboration  when  creating  the  highest  impact  and  lowest  cost 
solutions  possible,  should  be  a  top  business  imperative  of  the  Department 

Lack  of  trust  is  evident  throughout  the  DoD  Enterprise.  Oversight  is  often  conducted  by 
unqualified  individuals  or  oversight  groups  that  provide  untimely  and  unusable  analysis.  The 
lack  of  trust  by  leadership  and  oversight  bodies  is  causing  valuable  and  limited  resources  to  be 
spent  on  proving  vice  accomplishing  program  objectives.  This  creates  a  downward  spiral  of 
program  managers  forced  to  be  liaisons  rather  than  the  focal  points  for  program  execution.  It 
results  in  distractions  and  failures  causing  less  trust,  more  oversight,  and  an  additional  drain  on 
resources. 

Defining  and  executing  detailed  processes  by  the  OSD  PSAs  and  Service  Secretariats  sub¬ 
optimizes  the  Departments  and  communicates  a  level  of  distrust  in  the  organization. 

Lack  of  inclusion  of  those  most  affected  by  key  decisions  should  be  viewed  with  great  concern 
and  suspicion. 

Commanders’  intent  must  be  communicated  at  key  inflection  points  including  milestones  and 
budget  driven  changes.  High  impact  and  low  cost  solutions  should  be  rewarded,  especially  if  the 
solution  is  the  result  of  cross  collaboration  of  the  Service  Departments.  Being  clever  and 
innovative  should  trump  spending 1 1 . 


1 1  http://www.news.com.au/technologv/smartphones/iis-soldier-develops-iphone-app-to-target-the-taliban/storv- 
fn5sdlvk- 12259945658381 
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4.  Organizational  Alignment 


The  organizational  construct  of  the  DoD  is  both  complex  and  constrained.  Specific  findings, 
conclusions,  and  recommendations  are  presented  below. 

4.1  Findings 

The  organizational  constructs  and  operating  models  required  to  accomplish  the  business  of  the 
DoD  have  a  much  higher  order  of  complexity  than  any  commercial  business.  In  fiscal  year  2009, 
DoD  reported  that  it  had  over  $947  billion  in  disbursements,  $1.8  trillion  in  assets,  and 
approximately  3.2  million  military  and  civilian  personnel — including  active  and  reserve 
components.  DoD’s  2009  budget  would  rank  it  as  the  17th  largest  economy  in  the  world  based  on 
GDP,  according  to  the  CIA  World  Fact  Book.  Operations  span  a  wide  range  of  organizations, 
including  the  MilDep  and  their  respective  major  commands  and  functional  activities,  defense 
agencies  and  field  activities,  and  combatant  commands  that  are  responsible  for  military 
operations  for  specific  geographic  regions  or  theaters  of  operation  (e.g.,  CENTCOM,  PACOM, 
or  SOUTHCOM)  or  for  particular  areas  of  responsibility  (e.g.,  STRATCOM  or  TRANSCOM). 
To  execute  its  business  operations,  the  Department  performs  interrelated  and  interdependent 
business  functions  including  financial  management,  acquisition  and  contract  management, 
logistics  (e.g.,  supply  chain  management),  and  human  resource  management. 

The  Department  and  Services  are  not  designed  for  business  efficiency.  They  are  organized  and 
optimized  for  execution  of  their  warfighting  mission.  Further,  compromises  in  the  organizational 
design  are  deliberately  included  to  ensure  civilian  control  of  the  military,  which  increases 
business  inefficiency.  To  effect  civilian  control,  significant  power  has  been  vested  in  non¬ 
opera  tional  staff  roles  (stovepipes)  such  as  financial  management  and  logistics.  For  example,  the 
OSD  Principal  Staff  Assistants  (PSAs)  and  the  Secretariat  staffs  are  assigned  significant 
oversight  responsibility  over  the  activities  of  operational  commands,  which  would  not  be 
considered  an  efficient  construct  in  industry  because  it  inevitably  dilutes  accountability  and  blurs 
roles  and  responsibilities. 

Like  the  Department,  each  of  the  Services  is  responsible  for  many  different  but  interrelated  and 
interdependent  operations.  The  Army,  for  example,  runs  multiple  levels  of  depots,  various  supply 
chains,  hospitals,  school  houses,  construction,  design,  water  treatment,  energy  generation, 
humanitarian  aid,  courtrooms,  foreign  aid,  recruiting,  family  support  activities,  acquisition  of 
weapon  systems,  and  actual  warfighting  activities. 

These  organizational  constructs  have  caused  the  fragmented,  inconsistent,  and  redundant 
business  environment  that  exists  today,  characterized  by: 
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•  Disconnected  and  fragmented  business  processes  distributed  across  multiple 
organizations  within  and  outside  of  the  Service 

•  Diffuse  accountability  and  authority  for  overall  process  definition  and  execution  with  no 
single  person  or  entity  (Service  or  other  DoD)  responsible  for  the  efficiency  and 
effectiveness  of  any  end-to-end  process  at  the  Service  level 

•  Complex  cross-organizational  interdependencies; 

Service  organizations  are  designed  to  accommodate  the  need  for  on-demand  warfighting  mission 
requirements,  to  train  and  equip  forces,  and  to  comply  with  laws,  regulations,  policy,  and  OSD 
guidance.  Furthennore,  they  are  constrained  by  highly  change-resistant  cultures  shaped  by 
mission  and  history  and  the  lack  of  leverage  to  overcome  this  resistance  (e.g.,  ability  to  fire  or 
reassign  people  who  are  obstacles  to  change). 

The  ability  to  achieve  the  goals  of  business  modernization,  and  specifically  financial  visibility 
and  auditability,  requires  acknowledging  these  differences  and  operating  accordingly. 

DoD's  dissimilarity  to  a  commercial  business  goes  beyond  size  and  scale.  Commercial 
businesses  are  motivated  by: 

•  Making  a  profit 

•  Remaining  solvent 

•  Limiting  risk  and  liability 

•  The  implications  of  taxes  (valuation,  depreciation) 

These  have  limited  applicability  to  the  business  model  of  the  DoD.  Therefore,  DoD  financial 
statements  must  take  these  differences  into  account. 

Profit  is  certainly  not  a  driving  factor  for  DoD  operations.  Mission  success  is  the  most  important 
goal.  As  to  the  other  business  motivators: 

•  Solvency  is  not  an  issue. 

•  DoD  has  a  skewed  catastrophic  risk  profile  that  no  commercial  business  can  tolerate. 

•  DoD  is  self-insured  for  risk  including  loss  of  life,  environmental  clean-up,  and  obviously 
war. 

•  There  are  no  profit  or  tax  avoidance  incentives  to  drive  consideration  of  issues  like 
depreciation. 

DoD  cannot,  nor  should  it,  change  its  current  operating  model  to  one  that  is  more  like  a  business. 
Therefore,  any  strategies  and  approaches  to  business  modernization  and  financial  improvement 
must  provide  solutions  and  benefits  within  these  constraints. 

Solving  deep-rooted  business  problems  within  a  single  Service  is  a  false  sense  of  economy. 
Moreover,  a  few  enterprise-wide  solutions,  scoped  across  the  breadth  and  depth  of  functional 
stovepipes,  do  not  work. 
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When  responsibility  and  authority  are  separated,  hidden  cross-organizational  interdependencies 
result  in  no  clear  accountability. 

One  of  the  outcomes  of  the  Goldwater-Nichols  reorganization  of  the  Department  was  to  clearly 
separate  accountability  for  requirements  definition  from  the  acquisition  programs  that  are  put  in 
place  to  meet  those  requirements.  While  there  were,  and  remain,  valid  reasons  for  doing  this, 
how  this  is  accomplished  is  fundamentally  in  conflict  with  the  methodologies  that  have  been 
developed  for  successfully  fielding  COTS  ERP  systems.  ERP  programs  in  industry  seamlessly 
blend  the  development  of  requirements,  configuration  of  the  ERP,  design  and  creation  of  Report, 
Interface,  Conversion,  and  Enhancement  (RICE)  objects,  training,  execution  of  change 
management,  site  survey,  site  preparation,  data  conversion  and  rollout  under  the  control  of  a 
single  program  manager.  The  Department's  approach  separates  these  dependent  activities  under 
discrete  leadership  and  without  the  day-to-day  participation  of  a  single  accountable  leader  who 
can  quickly  make  decisions  across  all  these  elements  of  a  program.  The  result  is  much  slower 
decision  making  than  encountered  in  industry  programs.  This  a  contributing  factor  to  the 
excessive  size,  high  cost,  and  lack  of  success  in  the  fielding  of  the  ERP  programs. 

The  COCOMs  (who  are  the  customer)  have  the  responsibility  for  executing  military  operations. 
They  rely  on  the  outputs  of  the  Service  operational  commanders  (trained  and  equipped  forces) 
and  the  Defense  Agencies  (products  and  services).  The  execution  of  military  operations  and  their 
support  activities  generate  financial  transactions.  However,  the  executing  organizations  have  no 
accountability  for  and  are  not  measured  on  their  contribution  to  complying  with  legislative 
mandates  such  as  attaining  an  unqualified  audit  opinion  on  their  financial  statements,  the  priority 
of  the  functional  financial  community.  The  functional  community  has  not  made  the  case  for  why 
the  COCOMs,  Service  Operational  Commanders,  and  the  support  agencies  should  prioritize 
business  modernization,  financial  improvement,  and  business  process  efficiency  over  the 
business  of  Defense  Readiness  and,  as  stated  previously  in  this  study,  they  should  not. 

4.2  Conclusions  and  Recommendations 

Responsibility  must  be  directly  aligned  with  authority.  This  single  point  ensures  a  direct  line  and 
understanding  of  where  specific  accountability  for  perfonnance  lies.  A  leader  must  have  a  direct 
line  of  control  and  authority  over  decisions  for  which  he  has  responsibility. 

4.2.1  The  Department’s  goal  of  a  clean  audit  for  the  enterprise  appears  to  have  elevated 
auditability  to  a  level  similar  in  priority  to  warfighting.  The  priorities  of  leadership 
throughout  the  organization  (staffs  and  operational  commanders)  have  not  been  re¬ 
aligned  to  balance  the  priorities  of  these  goals  and  we  are  not  convinced  they  should 
be. 

Failure  to  align  goals  and  priorities  will  result  in  uneven  progress  toward  an  unpredictable 
destination  at  an  uncertain  pace.  Conversely,  aligned  goals  and  priorities  result  in  maximum 
progress  toward  a  unified  goal  in  a  predictable  timeframe.  To  overcome  this  lack  of  alignment, 
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the  Services  are  using  enterprise  level  ERP  to  attempt  to  force  a  unity  of  effort  and  outcome.  But 
because  ERP  cannot  be  the  forcing  function,  predictably,  the  Services  fracture  their  efforts  and 
systems. 

4.2.2  Given  the  complexity  and  diversity  of  each  Service  at  the  enterprise  level,  it  is 
infeasible  to  have  a  seamless  end-to-end  business  process  with  a  single-owner  with 
full  authority  and  accountability  to  define,  implement  and  execute  the  process. 

At  the  Service  enterprise  level,  the  only  leaders  with  the  authority  and  accountability  to  force 
concurrence  on  process,  requirements  and  authoritative  data  are  the  Secretary,  the  Under 
Secretary,  Service  Chief,  or  the  Vice  Chief.  They  would  have  to  make  this  their  number  one 
priority  with  engagement  on  a  day-to-day  basis.  Past  experience  in  DoD  has  shown  that  attempts 
to  delegate  this  authority  have  not  been  successful. 

ERP  cannot  be  implemented  in  an  environment  where  wide  concurrence  is  required  unless  there 
is  a  person  who  has  the  authority  and  willingness  to  quickly  resolve  conflicts  in  a  manner 
binding  on  all  participants.  The  level  at  which  a  leader  can  be  identified  with  the  authority  and 
accountability  to  do  this  defines  the  level  in  the  organization  at  which  ERP  can  be  successfully 
implemented.  ERP  systems  are  not  designed  to  be  implemented  via  consensus  alone — they 
require  at  least  a  benevolent  dictatorship. 

4.2.3  The  Services’  choice  to  implement  ERPs  without  making  substantial  organizational 
and  business  process  changes,  combined  with  DoD  mandated  direction  to  utilize 
portions  of  the  legacy  environment,  has  resulted  in  programs  with  unmitigated 
levels  of  risk  to  cost,  schedule  and  performance. 

Complexity  is  manifested  in  the  number  of  users,  organizational  boundaries  to  be  crossed, 
system  interfaces,  processes,  stakeholders’  geographic  locations,  volume  of  data,  program  office 
size,  level  of  resistance  to  change  and  fit  of  the  ERP  to  the  business  requirements.  With  this  level 
of  complexity,  accurate  prediction  of  cost,  schedule,  and  perfonnance  is  impossible. 

A  critical  success  factor  in  the  implementation  and  fielding  of  COTS  systems  is  the  willingness 
of  an  organization  to  embrace  the  change  necessary  to  adopt  the  tool  without  customization.  The 
Department  of  Defense  and  the  Services  are  noted  for  their  cultural  resistance  to  change  and 
therefore  are  ill  suited  to  COTS  on  an  enterprise-wide  scale. 

The  DCMOs  must  become  trusted  agents,  acting  as  honest  brokers  between  the  competing 
interests  of  the  staffs  in  their  roles  as  policy  makers  and  oversight  and  those  charged  with 
executing  the  warfighting  support  mission  of  the  Services.  Figure  4  depicts  the  DoD  and  Military 
Department  DCMOs  and  the  organizations  whose  priorities  they  must  balance  to  ensure  DoD  is 
efficient  and  effective  in  its  warfighting  mission  first  along  with  its  accountability  to  the 
taxpayer. 
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The  Military  Department  DCMOs  should  perform  this  function  between  the 
competing  interests  within  the  Services  while  the  DoD  DCMO  should  perform  a 
parallel  role  within  the  OSD  staffs  and  among  the  Military  Department  DCMOs 

Figure  4.  DCMO  Balancing  Competing  Priorities 


The  Military  Department  DCMOs  should  provide  the  business  portfolio  view  and  collective 
position  of  their  Services.  They  should  be  qualified  to  sufficiently  represent  the  Services’ 
position  at  a  fairly  detailed  level  to  the  OSD  DCMO.  The  Military  Department  DCMOs  must 
also  be  the  Chief  Collaboration  Officers  between  their  Departments  and  sister  Services,  to  ensure 
best  practices  are  leveraged  and  the  best  of  the  DoD  is  brought  forward  for  the  benefit  of  the 
whole  DoD. 

The  Military  Department  DCMOs  should  have  the  authority  commensurate  with  the 
responsibility  for  the  strategy  and  execution  of  business  modernization  for  their  Departments  and 
Services.  This  should  include  the  systems  and  ancillary  resources  associated  with  these 
programs. 
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5.  People  and  Culture 


The  strengths  and  consequences  of  the  attributes  native  to  the  DoD  personnel  and  culture  are 
presented  in  the  findings,  conclusions,  and  recommendations  below. 

5.1  Findings 

Sheer  will  and  the  “can-do”  professionalism  of  DoD  personnel  can  be  a  detriment  to  the  very 
department  they  serve  when  assessing  the  state  of  IT  investments. 

5.1.1  Discussion  is  sometimes  confused  with  dissent.  A  risk-averse  or  hyper-chain-of- 
command  mindset  discourages  subordinates  from  revealing  factual,  but  contrary 
information  that  may  be  important  to  a  decision.  This  “can-do”  attitude  can  convey 
a  false  sense  of  progress. 

The  historic  command-and-control  approach  of  the  military  has  led  to  a  cultural  reluctance  to 
push  back  on  the  decisions  of  superiors  by  subordinates  even  when  the  subordinate  has  a  fact- 
based  case  for  doing  so.  Conversely,  some  leaders  do  not  appreciate  the  courage  required  for 
having  decisions  questioned  by  subordinates.  The  culture  does  not  encourage  delegation  of 
authority  to  make  binding  decisions  at  the  minimum  level  possible.  This  results  in  slow  decision¬ 
making  and  decisions  being  revisited.  Both  of  these  factors  drive  cost  and  schedule  growth  in  the 
implementation  of  the  ERP  systems.  This  has  also  led  to  ineffective  and  overly  fonnalized 
delivery  of  information  through  an  extensive  control  hierarchy.  The  status  of  a  given  program 
becomes  more  and  more  positive  and  less  and  less  accurate  as  it  makes  its  way  through  the 
hierarchy  until,  by  the  time  it  reaches  senior  leaders,  there  are  no  problems.  The  result  of  this  is 
that,  when  bad  news  finally  reaches  leaders,  their  trade-space  for  making  meaningful  changes  in 
direction  is  limited  or  non-existent. 

Program  managers  are  unable  to  deliver  a  completely  factual  version  of  their  status  to  leadership 
if  it  contains  any  element  that  could  be  considered  significantly  negative.  To  do  so  is  perceived 
as  weakness  in  execution  even  though  the  root  causes  may  be  out  of  the  control  of  the  program 
manager.  Program  managers  fear  that  an  honest  delivery  of  program  status  will  result  in 
cancellation.  As  a  result  of  this,  leadership  is  unable  to  be  effective  in  removing  obstacles  to 
program  success. 

5.1.2  The  vested  interest  in  keeping  programs  on  cost  and  schedule  at  the  expense  of 
performance  delays  the  realization  that  you  “can’t  get  there  from  here.”  Cost  and 
schedule  are  highly  visible  measures,  but  program  performance  is  not  visible  until 
the  program  reaches  the  test  phase  or  is  in  a  production  environment.  This 
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perpetuates  the  continuation  of  investment  in  poorly  executing  programs.  It  takes 
courage  to  say  “no”  and  cancel  a  program. 

Few  are  willing  or  incentivized  to  stop  poorly  performing  programs.  In  many  cases  there  are 
disincentives  for  stopping,  including  the  political  costs  associated  with  recognizing  that  sunk 
costs  have  realized  little  or  no  value.  Problems  within  the  ERP  programs  are  largely  known  and 
privately  recognized.  However,  implementing  anything  other  than  marginal  changes  in  direction 
without  encountering  institutional  barriers — such  as  acquisition  policy,  federal  acquisition 
regulations,  and  budget  process — is  limited. 

5.1.3  There  is  a  lack  of  trust  between  Congress,  OSD,  the  Component  staffs,  and  the 
operational  commands  that  drives  excessive  oversight  by  GAO,  the  DoD  IG, 
Components,  and  OSD  staffs.  It  is  distracting  to  programs. 

A  circular  situation  exists  where  lack  of  trust  drives  excessive  oversight,  which  in  turn  negatively 
impacts  program  execution.  Mutual  trust  further  erodes  and  oversight  increases  once  more. 
Program  managers  spend  most  of  their  time  managing  the  oversight  instead  of  running  their 
programs.  Despite  the  findings  of  all  of  these  oversight  bodies,  the  problems  of  the  ERP 
programs  persist  without  major  changes  in  direction  or  program  cancellation.  Program  Managers 
describe  the  oversight  of  the  ERP  programs  as  excessive,  burdensome,  and  destroying  more 
value  than  it  creates  for  the  Department,  the  warfighter,  and  the  taxpayer. 

Oversight  activities  are  not  consistent.  For  example,  senior  leaders  and  managers  of  programs 
said  that  certain  IT-focused  personnel  from  GAO  were  generally  better  prepared  and  more  open 
minded  in  their  approach.  The  IG  was  not  as  qualified  on  basic  details  and  notably  behind  the 
power  curve  in  terms  of  current  status  of  the  programs  they  were  assessing.  This  lack  of 
awareness  required  program  personnel  to  divert  from  program  priorities  to  bring  oversight 
personnel  up  to  speed. 

Oversight  does  not  cause  the  problems  a  program  encounters,  nor  is  it  responsible  for  the  cultural 
imperative  to  only  forward  good  news.  Multiple  and  redundant  oversight  is  a  direct  result  of  our 
fractured  system  of  government,  diffuse  accountability  and  responsibility,  and  is  a  RESPONSE 
to  the  well-known  culture  that  calls  for  only  passing  the  boss  good  news.  The  oversight  problem 
emerges  because  we  have,  in  the  first  instance,  drawn  the  boundaries  around  the  ERP  too  vastly. 
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5.1.4  DoD  views  business  modernization  and  financial  improvement  problems  as  IT 
system  problems  not  operational  problems.  DoD  is  trying  to  solve  business 
modernization  and  financial  improvement  problems  that  span  the  entire  Doctrine, 
organization,  training,  materiel,  leadership  and  education,  personnel  and  facilities 
(DOTMLPF)  spectrum,  including  auditability,  by  focusing  primarily  on  systems. 

DoD  and  the  Services  do  not  appear  to  understand  the  full  scope  of  the  problem  they  are  trying  to 
solve.  Many  senior  leaders  interviewed  believe  that  ERP  can  be  used  to  force  the  changes  that 
are  required  to  create  an  environment  where  auditability  can  realistically  be  achieved. 

These  required  changes  include  components  of  policy,  process,  organizational  structure, 
personnel,  and  training.  These  changes  cannot  realistically  be  made  within  just  an  acquisition 
program.  Industry  and  DoD  experience  to  date  have  proven  that  fundamental  changes  must  be 
made  prior  to  and  then  enabled  by  an  ERP  program  or  other  IT  enabler. 

5.1.5  There  is  a  widespread  and  erroneous  assumption  that  the  enabling  technology  can 
be  used  to  force  business  process  and  organizational  change. 

The  Services  are  depending  upon  the  ERP  software  to  force  changes  in  organizational  behavior 
and  in  business  processes  in  direct  contradiction  to  the  proven  approaches  of  industry.  Industry 
and  DoD  have  proven  that  changes  to  organization  and  business  process  are  an  outcome  of 
extensive  change  management  activities  that  are  largely  a  precursor  to  the  ERP  implementation. 
While  ERP  software  provides  a  library  of  best  practice  business  processes,  it  is  not  a  strategic 
organizational  change  management  tool  that  can  force  their  implementation. 

5.2  Conclusions  and  Recommendations 

DoD  leadership  must  recalibrate  personnel  to  accept  that  quitting  or  strategically  pausing  to 
reassess  direction  or  value  can  translate  to  a  win  for  the  Department.  Leaders  should  be  as  open- 
minded  to  those  who  have  the  courage  to  say  "no"  or  "no  more"  as  they  are  to  those  who  say 
"can  do." 

Government  personnel  providing  oversight  for  ERP  systems  must  be  as  knowledgeable  about 
their  implementation  as  the  contractor  or  system  integrator.  Absence  of  this  level  of  expertise  has 
a  negative  and  lasting  effect  on  the  ability  of  the  DoD  to  fulfill  its  fiduciary  responsibility  to  the 
American  public. 

Redundant  layers  of  oversight  and  subsequent  audits  and  briefings  are  distracting,  costly,  and 
detrimental  to  program  performance.  The  Military  Department  DCMOs  in  conjunction  with  the 
OSD  DCMO,  should  conduct  an  immediate  assessment  of  the  multiple  internal  and  external 
briefing  activities  and  make  solid  recommendations  to  reduce  these  briefings  to  the  most  optimal 
balance  between  oversight  and  execution  efficiency.  This  will  demand  tremendous  collaboration, 
coordination,  and  reduction  of  governing  bodies,  but  it  is  critical  to  the  successful  and  timely 
fielding  of  business  systems. 
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The  Congress,  OSD  and  the  Service  or  Component  all  burden  the  programs  and  their  sponsors 
with  reporting  requirements  and  excessive  oversight  that  does  not  add  value  in  achieving  the 
needed  capabilities  for  the  Department.  Much  of  the  oversight  is  duplicative  or  overlapping,  for 
example  where  Service  or  Component  oversight  reviews  and  comments  are  followed  by  identical 
reviews  by  OSD  staff.  Similarly  IG,  OMB,  GAO,  Service  audit  agencies,  and  others  perform 
reviews  that  are  not  coordinated  and  result  in  multiple  redundant,  and  potentially  conflicting, 
data  calls. 

The  Department’s  processes  for  requirements  definition  and  acquisition  (JCIDS  and  DoD  5000 
Series  policies)  do  not  align  well  to  the  needs  of  the  acquisition  of  COTS  business  systems  and 
have  driven  them  away  from  implementing  the  methodologies  and  approaches  to  implementation 
and  fielding  that  have  proven  successful  in  industry. 
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6.  Architecture,  Processes,  and  Systems 


Compliance  must  be  balanced  with  performance.  Our  findings,  conclusions  and 
recommendations  are  presented  below. 

6.1  Findings 

6.1.1  The  Services  have  taken  fully  integrated  ERPs  and  forced  them  into  their  highly 
fragmented  organizational  and  management  construct,  business  processes,  legacy 
systems  and  data  sources  at  the  Service  enterprise  level. 

In  most  cases,  the  Services  are  implementing  ERP  at  the  enterprise  level,  which  requires  them  to 
cross  many  internal  and  external  organizational  boundaries  that  are  outside  the  span  of  control  of 
any  single  functional  sponsor.  This  creates  an  environment  where  the  person  in  charge  typically 
does  not  have  authority  or  the  accountability  over  all  of  the  impacted  organizations  and 
stakeholders,  the  business  process,  legacy  systems,  and  data  sources.  The  consequence  of  this  is 
the  need  to  break  apart  the  inherent  integration  within  ERP  systems  and  then  rebuild  it  using 
interfaces  and  customizations  to  accommodate  the  fragmented  organizational  process,  legacy 
system,  and  data  landscape. 

In  reality,  the  integrity  of  the  ERP  implementations  in  the  Department  are  compromised  as  a 
result  of  the  Department  and  Service-mandated  integration  with  legacy  systems.  The  reasons  for 
the  persistence  of  legacy  systems  are  complex  and  cover  a  wide  range  of  reasons  such  as: 
immutable  business  process  requirements  not  found  in  industry  e.g.,  Special  Ops/Intel  troops 
operating  covertly),  resistance  to  change,  lack  of  authority  of  the  functional  sponsor  to 
implement  the  business  process  changes  required,  and  inadequate  understanding  of  the 
capabilities  of  the  ERP.  The  inherent  integration  of  the  ERP  is  the  fundamental  value  proposition 
for  using  an  ERP’s  FULL  capability  and  the  cornerstone  of  its  ability  to  support  auditability 
goals. 

6.1.2  ERP  does  not  equal  Auditability 

There  is  confusion  about  the  connection  between  the  ERP  and  auditability.  The  Services  are 
using  the  ERP  as  the  primary  enabler  for  business  modernization  and  financial  improvement 
because  it  is  perceived  that  the  ERP  provides: 

•  Enforcement  of  referential  integrity  across  all  dependent  data  elements 

•  Transactional  traceability 

•  Visibility  of  key  information  (budget  execution,  assets) 
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•  Improved  operational  controls 

•  Cost  accounting 

•  Minimal  manual  intervention  for  reconciliation 

•  Seamless  business  process  execution  across  and  between  functional  stovepipes 
However,  this  is  not  the  way  the  systems  are  being  implemented. 

6.1.3  There  is  overlap  in  capability  that  the  ERP  software  can  provide.  However,  this 
should  not  be  confused  with  the  necessary  business  processes  that  are  driven  by  the 
unique  aspects  of  the  missions  of  each  Service. 

A  given  ERP  software  package  might  be  capable  of  supporting  each  Service  enterprise  end-to- 
end,  and  capabilities  may  completely  overlap  at  the  highest  level.  While  these  systems  are 
automating  the  operational  activities  that  comprise  similar  high-level  end-to-end  processes,  they 
differ  in  configuration  at  the  detailed  level,  given  the  mission  needs  of  the  Component  they 
support.  Just  as  one  sees  overlapping  capabilities  across  the  Component  enterprise  systems,  there 
are  overlaps  in  functionality  between  Component  and  DoD  enterprise  systems.  In  most  cases, 
these  specific  or  unique  business  rules  are  in  place  for  very  good  reasons.  For  example,  the 
operating  model  for  the  Army  is  different  from  that  of  the  Marine  Corps,  driven  by  differences  in 
mission. 

6.1.4  There  are  processes  within  the  Department  that  simply  have  no  analog  in  industry 
or  even  in  other  Governments.  This  explains  the  persistence  of  many  legacy  systems 
in  the  target  environment. 

An  invalid  premise  underpinning  the  use  of  ERP  software  is  that  it  has  the  capability  to  meet  all 
of  the  needs  of  the  Department  or  that  they  can  be  met  by  some  combination  of  customization 
and  change  of  business  process  and  policy.  The  default  premise  of  the  DoD  assumes 
standardization  is  good  across  the  board  without  testing  whether  the  standardization  adds  value 
to  achieve  the  mission  or  is  worth  the  cost  and  effort  to  achieve. 

For  example,  certain  capabilities  of  the  Mechanization  of  Contract  Administration  System 
(MOCAS)  are  not  easily  available  in  the  ERPs.  These  capabilities  include  the  entitlement  of 
complex  payments  on  cost-plus  contracts.  Other  mandated  systems  include  Standard 
Procurement  System  (SPS),  Wide  Area  Work-flow  (WAWF),  and  an  array  of  disbursing 
systems.  An  even  more  dramatic  example  was  the  DIMHRS  program,  where  the  demands  of 
statutory  requirements  not  encountered  in  the  private  sector  drove  extensive  customization 
supporting  hundreds  of  entitlements  and  pay  types,  promotion  boards,  and  strength  management 
and  contributed  to  the  eventual  demise  of  that  program.  The  Department  should  implement  an 
ERP  for  what  it  is  designed  for  and  interface  only  where  the  ERP  is  not  designed  to  perform  the 
function. 
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6.1.5  The  Services’  ERP  programs  are  unprecedented  in  terms  of  size  and  complexity  as 
measured  by  combinations  of  the  following  parameters:  number  of  users,  size  of 
program  office,  number  of  discrete  organizations  involved  and  organizational 
boundaries  crossed,  number  of  geographic  locations,  number  of  ledger  accounts, 
number  of  stock  keeping  units  (SKUs),  number  of  asset  records,  and  other  key 
indicators. 

When  considered  together,  these  factors  represent  size  and  complexity  never  encountered  in 
industry  and  well  past  the  point  where  the  technology  is  proven  to  scale.  Further,  the  program 
size  as  a  factor  in  feasibility  or  success  of  the  program  transcends  questions  of  technical 
scalability.  There  is  a  significant  correlation  between  increasing  size  of  the  program  team  and 
failure  rate  in  industry  [Dr.  Dobbs  2010  Survey  of  IT  Program  Success  Factors.]  In  ERP 
implementations,  the  effort  required  to  gain  consensus  on  many  issues,  including  requirements, 
is  a  significant  driver  of  cost  and  schedule,  and  the  number  of  people  involved  in  the  Services’ 
ERP  programs  is  an  order  of  magnitude  larger  than  any  example  from  industry.  These  factors 
introduce  high  levels  of  uncertainty  and  risk  into  the  cost  and  schedule  estimates  for  the  ERP 
programs. 

Despite  the  shortcomings  identified  during  this  assessment,  some  of  the  Services’  ERP  programs 
are  being  fielded  and  have  replaced  legacy  systems,  particularly  in  logistics  and  operations. 
Therefore  the  notion  of  totally  abandoning  the  ERPs  cannot  easily  be  accomplished  without 
significant  disruption  to  various  operations  within  the  Services  and  is  without  merit. 

The  problems  of  addressing  the  entire  spectrum  of  DOTMLPF  required  to  actually  achieve 
modernization  and  financial  improvements  are  so  complex  that  senior  leaders  in  the  Department 
are  tempted  to  act  as  though  technical  choices  alone  can  solve  the  problems.  Moreover,  IT 
enablers  alone  cannot  be  a  forcing  function  for  organizational  and  business  process  change. 
Rather,  the  willingness  and  ability  of  senior  leadership  to  make  these  changes  is  the  critical 
constraint  that  must  be  overcome  to  make  a  technical  solution  feasible. 

6.2  Conclusions  and  Recommendations 

New  procurement  costs  for  the  enterprise  must  be  balanced  against  costs  to  sustain  and  maintain 
legacy  systems  including  fielded  ERPs  that  are  operational  and  have  a  significant  user  base.  The 
enterprise-level  architecture  needs  to  be  the  backbone  for  interoperability  and  portfolio 
management,  and  communicate  the  strategy. 

6.2.1  ERPs  simply  enable  the  Services  to  execute  the  auditable  business  process  efficiently 
and  effectively.  The  reality  is  that  even  if  all  the  ERPs  were  fielded  tomorrow, 
auditability  would  not  be  achieved. 

Today,  progress  towards  auditability  or  clean  financial  statements  is  largely  being  measured  by 
the  Department’s  ability  to  implement  and  field  their  large  financial  ERPs.  Auditability  and  the 
ability  to  produce  clean  financial  statements  should  be  the  natural  by-product  of  a  high- 
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performing  organization.  End-states  such  as  full  traceability  and  transaction  integrity  are 
automatically  achieved  when  organizational  structure,  people  behavior,  business  processes  and 
rules  (within  internal  controls),  policy,  and  technology,  are  integrated  and  measured  to  ensure 
successful  outcomes.  Technology  and  ERP  systems  simply  enable  the  Service  or  the  Department 
to  efficiently  and  effectively  execute  the  auditable  business  process. 

DoD  should  strive  to  enable  the  full  use  of  capabilities  of  the  ERPs  by  actively  phasing  out  the 
requirements  to  go  outside  the  ERP  (e.g.,  financial  transactions  such  as  accounts  payable  and 
accounts  receivable  as  contained  in  WAWF,  various  DFAS  interfaces)  and  spending  monies  to 
shut  down  interfaces  to  systems  that  no  longer  offer  unique  functionality  and  absorbing  these 
transactions  into  the  ERP. 

The  Department  cannot  be  reasonably  compared  to  a  commercial  business,  even  a  large  one  with 
a  global  footprint.  The  DoD  is  more  accurately  compared  to  an  economy,  with  all  the  attendant 
complexity.  The  Department  and  the  Services  need  to  craft  a  strategy  that  recognizes  this 
complexity  and  align  its  IT  strategies  accordingly.  This  strategy  should  address,  at  a  minimum: 

•  The  reality  of  the  new  budget  environment. 

•  The  continued  use  or  expansion  of  current  (legacy)  systems  where  there  is  a  large  and 
satisfied  user  community  and  the  cutover  of  the  new  ERP  is  delayed  or  not  meeting 
performance  expectations. 

•  If  an  ERP  is  delayed  or  still  immature,  incentivize  the  Services  to  use  the  functionality  of 
an  ERP  that  is  already  functional  in  other  Departments  or  Agencies. 

The  Business  Enterprise  Architecture  (BEA)  should  be  a  repository  for  standards  (particularly 
data  standards)  not  prescriptive  of  process.  The  BEA  must  describe  the  target  vision  as  a  critical 
first  step  to  serve  as  a  basis  for  the  system’s  concept  of  operations  (CONOPS) 

The  BEA  should  be  integrated  with  other  data  repositories,  such  as  the  OMB  Exhibits  and  the 
DoD  IT  Portfolio  Repository  (DITPR),  to  provide  a  master  set  of  capabilities,  activities,  and 
processes  that  support  the  business  mission  area  and  the  business  of  the  Department.  See 
Appendix  E  for  further  discussion. 

The  federated  BEA  should  provide  the  blueprint  for  the  individual  systems’  data,  including: 

•  Standard  organizational  building  blocks  of  the  Department 

•  Processes,  the  unique  process  requirements  of  the  organizational  units  that  execute 
them,  the  process  maturity,  and  the  placement  of  ERP  and  other  systems 

•  Mapping  of  capabilities,  activities,  and  processes  to  the  organizational  units  that 
execute  them 

•  Architecture  standards,  such  as  application  of  the  BPMN 

•  Recommended  comprehensive,  quantitative  perfonnance  metrics 
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•  guidance  on  key  architecture  steps,  such  as  how  to  record  business  events  as  triggers 
and  outcomes  in  the  architecture 

A  more  complete  discussion  of  the  Architecture  can  be  found  in  Appendix  E  with  architecture 
artifacts  in  Appendix  J  (accompany  CD). 
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7.  Metrics 


7.1  Findings 

Positive  incentives  to  change  behavior  have  to  impact  people  directly;  that  is,  incentives  must 
align  with  the  results  desired.  Currently  there  is  a  negative  consequence  if  a  system  owner  or 
program  manager  does  not  spend  the  entire  budget  allocated  to  a  particular  program  within  a 
certain  period  of  time.  The  goal  must  be  to  incentivize  rewards  with  tight  congruence  within  a 
family  (or  portfolio)  of  IT  investments  to  fulfill  a  common  purpose.  See  appendix  D  for  further 
discussion  on  perfonnance  measures. 

7.1.1  There  is  an  absence  of  comprehensive  metrics  baselining  the  current  business 
operating  environment  and  quantifying  desired  outcomes.  The  consequence  is  the 
inability  to  prove  progress  toward  achieving  business  improvements  leading  to 
auditability. 

Defining  the  overall  day-to-day  operational  state  of  business  is  not  comprehensive  in  the 
Services.  There  are  individual  metrics,  such  as  interest  paid,  that  define  the  perfonnance  of 
segments  of  the  overall  business  process.  For  example,  prompt  pay  is  easily  understood  and  easy 
to  measure.  Auditability  is  not  a  one-to-one  linear  concept  and  is,  therefore,  difficult  to  measure. 
This  drives  behaviors  that  lead  to  undesirable  conditions  such  as  unmatched  disbursements. 

7.2  Conclusions  and  Recommendations 

Our  interviews  indicate  that  Department  reports  are  produced  and  the  box  is  checked,  but  there  is 
little  confidence  that  performance  metrics  (or  the  data)  are  realistic.  Compliance  aspects  and 
deadlines  are  met  but  often  an  authentic  ground-truth  understanding  of  program  performance  is 
not. 

7.2.1  Compliance  with  law  and  policy  is  being  used  as  the  primary  metric  of  program 
progress.  This  is  a  false  indicator. 

DoD  relies  upon  compliance  with  OSD  acquisition  policy,  the  BEA,  and  attainment  of 
acquisition  milestones  and  budget  executed  as  the  indicators  of  program  progress.  None  of  these 
is  a  reliable  measure  of  progress  towards  the  delivery  of  usable  capability  supporting  the  larger 
goals  of  business  modernization  and  financial  improvement. 

Checklist  compliance  (cost,  schedule)  should  not  be  a  substitute  for  high  perfonnance. 

The  Department  should  require  functional  proponents  of  business  systems  and  programs,  such  as 
the  ERPs,  to  develop  a  consolidated,  detailed  business  case  with  a  compelling,  unimpeachable 
justification  for  selecting  and  implementing  a  proposed  solution. 
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A  detailed  root  cause  analysis  of  the  problem  the  proponent  is  trying  to  solve  and  a  discrete  set 
of  measurable  operational  outcomes  (improvements  or  new  capability)  derived  from  an  existing 
baseline  should  support  the  business  case. 

This  business  case  would  help  the  functional  proponent  and  oversight  authorities  ensure 
progress,  keep  outcomes  in  alignment,  and  validate  the  need,  approach,  cost  and  benefits  to 
justify  continued  funding  and  support.  Business  Case  Analyses  (BCAs)  provide  the  ability  to 
prevent  scope  and  requirements  growth,  as  all  proposed  changes  must  be  looked  at  in  terms  of 
impact  on  the  original  purpose  of  the  program.  Equally,  BCAs  provide  leverage  to  stop  programs 
that  no  longer  meet  the  intended  need  or  to  show  that  the  original  problem  no  longer  exists  or  has 
changed  enough  to  require  a  new  BCA  and  potentially  a  different  solution. 

System  integrators  cannot  be  the  main  source  of  information  on  a  business  case  for  an  ERP. 
They  are  not  the  business  owners  or  customers  and  likely  have  a  conflict  of  interest. 

7.2.2  There  is  an  assumption  that  compliance  is  adequate  to  ensure  program  execution 
and  performance  of  the  delivered  capability  in  the  operating  environment. 

When  considering  favorable  or  adverse  actions  regarding  the  current  ERP  programs,  the  success 
or  failure  of  such  programs  should  consider: 

•  Benefit  to  users 

•  Number  of  users  now  (and  in  the  near  future) 

•  Legacy  system  costs 

•  All  labor  costs  (including  military,  civilian)  associated  with  the  legacy  systems  (e.g., 
manual  intervention) 

•  Voice  and  satisfaction  of  the  current  customers 

•  Operational  viability 

•  Risk  of  continuing  or  quitting 

The  already  sunk  cost  of  the  systems,  while  troublesome,  should  not  be  the  primary  reason  for 
continuing  an  ERP  or  program.  It  is  a  false  sense  of  economy. 

The  assessment  and  validation  of  these  metrics  should  be  reviewed  by  a  board  of  peers  related  to, 
but  outside  of  the  Department  assessed.  For  example,  a  board  with  the  PMs  from  Army,  Air 
Force,  Department  of  Homeland  Security  (DHS),  Federal  Trade  Commission  (FTC),  and  others 
would  review  the  Navy  ERPs.  The  participants  from  outside  the  DoD  would  be  Departments  or 
agencies  that  have  endured  similar  challenges  and  have  a  holistic  and  fairly  reasonable  point  of 
view. 
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8.  Principal  Findings  and  Conclusions 


Attaining  the  goal  of  making  the  Department  an  auditable  enterprise  is  a  wicked  problem. 

8.1  The  IDA  team  is  not  confident  that  DoD’s  current  ERP  implementation 
strategy  will  deliver  the  expected  capabilities  on  time  and  within  budget. 

The  term  wicked  problem  is  used  to  describe  problems  in  social  planning  that  are  difficult  or 
impossible  to  solve.  Achieving  a  solution  is  impossible  or  nearly  so,  and  this  is  not  easily 
recognized  because  of  incomplete,  contradictory,  and  changing  requirements.  Further,  the 
existence  of  complex  interdependencies  often  leads  to  a  situation  where  attempting  to  solve  one 
aspect  of  a  wicked  problem  reveals  or  creates  other  problems. 

The  problem  of  achieving  auditability  in  the  Department  meets  most  or  all  of  the  ten 
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characteristics  of  wicked  problems  described  by  Rittel  and  Webber's  (1973)  formulation  of 
wicked  problems. 

The  commercial  business  goals  of  making  a  profit,  remaining  solvent,  and  limiting  risk/liability, 
and  the  implicit  tax  strategies  (valuation  and  depreciation)  are  inconsistent  with  the  DoD 
business  model.  This  leads  to  the  conclusion  that  the  Department  as  a  whole  and  the  MilDep 
have  a  higher  congruency  with  “Defense  as  an  economy”  rather  than  “Defense  as  a  commercial 
business.” 

This  has  profound  implications  regarding  the  value  of  comprehensive  commercial-style  financial 
statements  (e.g.,  valuation  of  military  equipment).  The  federal  government  answers  to  taxpayers, 
not  shareholders,  as  its  primary  stakeholders.  For  example,  tax  incentive-based  approaches 
regarding  valuation  and  depreciation  of  assets  have  minimal  operational  value  to  DoD  managers 
and  operators.  However,  existence  and  completeness  of  said  assets  are  important  business 
indicators  AND  valuable  to  the  operations  of  the  DoD.  A  more  meaningful  accounting  of  the 
DoD  would  be  a  cost  accounting  approach. 

As  for  capability  overlaps,  the  Services  and  Agencies  have  different  missions.  At  the  DoD 
enterprise  level  apparent  capability  overlaps  reflect  different  capabilities  at  the  operational  or 
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transactional  level  to  support  specific  business  operations  and  missions  of  the  Department.  At  the 
Service  and  Agency  overlapping  missions  could  equate  to  capability  overlap,  but  consolidating 
these  capability  overlaps  into  the  DoD  enterprise  could  break  the  overall  business  process  within 
a  Service  or  Agency. 


Each  of  the  Service  ERPs  is  implementing  a  different  subset  of  the  Service’s  business  processes. 
However,  the  subsets  have  not  been  selected  based  upon  the  natural  design  of  the  ERP  and,  in 
general,  the  functionality  addresses  a  small  fragmented  portion  of  the  business  process  across 
multiple  chains  of  command,  rather  than  addressing  a  large  contiguous  portion  of  the  business 
process  across  a  single  chain  of  command.  For  example,  DLA  implemented  its  ERP  for  a  single 
chain  of  command,  while  GFEBS  is  scoped  to  a  narrow  portion  of  the  accounting  functions  of 
the  General  Fund  for  all  MACOMs  in  the  Army.  This  is  different  from  running  the  entire 
business  operations  of  a  single  MACOM  such  as  Forces  Command,  which  would  conform  to  the 
inherent  design  of  the  ERP  and  make  it  less  of  a  wicked  problem. 

Additionally,  transactions  are  not  contained  within  a  single  ERP  but  happen  across  multiple 
organizations;  each  organization  (the  set  of  processes  within  DoD  itself  or  of  a  Service  or 
Defense  Agency)  controls  what  data  it  passes  on  to  the  others — there  is  no  real  federation  across 
multiple  ERP  implementations — without  appropriate  attention  to  aligning  the  interfaces.  This 
approach  cannot  produce  a  coherent  system  across  the  DoD  enterprise. 

The  Department’s  new  Chief  Management  Officer  (CMO)  construct  for  business  operations  may 
provide  the  top-level  support  needed  to  break  through  the  organizational  friction  points  caused 
by  the  functional  stovepipes  in  the  overall  DoD  enterprise.  The  DoD  has  made  progress  in  many 
business  areas,  including  improper  payments,  instituting  internal  controls,  and  vendor 
compliance.  However,  consistent  and  sustainable  enterprise-wide  gains  must  still  be  achieved. 

8.2  Overarching  Recommendations 

The  commercial  business  goals  of  making  a  profit,  remaining  solvent,  and  limiting  risk/liability, 
and  the  implicit  tax  strategies  (valuation  and  depreciation)  are  inconsistent  with  the  DoD 
business  model.  DoD  and  Congress  need  to  assess  the  DoD  business  model  ,  understand  how  it 
differs  from  a  corporate  business  model,  and  apply  the  appropriate  information  technology 
solution(s)  for  the  DoD  business  model.  Furthermore,  the  financial  representation  of  DoD’s 
business  must  take  into  account  these  differences. 

The  DoD  should  stop  the  pursuit  of  comprehensive  financial  statement  audits.  Instead,  audit 
readiness  with  a  specific  focus  on  the  Statement  of  Budgetary  Resources  (SBR)  should  be 
accomplished.  Furthermore,  all  other  audit  readiness  activities  should  be  evaluated  as  to  their 
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Headquarters,  operational,  and  supporting  organizations  and  how  these  organizations  meet  the  objectives  of  a 
federal  defense  agency.  Understand  what  success  means  for  these  organizations. 
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operational  value  before  resources  are  expended.  For  example,  asset  visibility,  existence,  and 
completeness  are  critically  important  from  compliance  and  operational  perspectives  and  are 
therefore  high  value  activities.  The  accounting  of  costs  should  be  the  primary  focus  of  the 
Department. 

Where  there  is  no  significant  deployed  user  base  of  an  Service-level  ERP,  the  DoD  should  curtail 
the  deployment  of  the  ERP  in  FY12  and  beyond,  pending  a  thorough  review  of  the 
organizational  environment  in  which  the  ERP  will  operate,  clear  definition  of  the  problem  the 
ERP  is  attempting  to  solve,  detennination  of  the  alignment  with  ERP  capabilities,  and 
development  of  an  implementable  data  strategy. 

Furthermore,  the  DoD  should  define  a  way  forward  based  upon  solutions  at  a  level  in  the 
organization  where  a  single  accountable  leader  has  the  span  of  control  to  define,  implement, 
and  execute  the  end-to-end  business  processes  the  IT  investment  is  intended  to  support.  In  doing 
so,  DoD  should: 


•  Obtain  a  clear  understanding  of  today’s  business  problems  -  taking  into  account 
improvements  and  changes  (e.g.,  policy,  deployments  of  other  IT  investments)  that  may 
have  been  made  to  processes  outside  the  ERP  program  since  its  inception. 

•  Recognize  organizational  constraints — both  mission  and  political — and  demand 
verification  of  activities  that  are  geared  towards  performance,  not  just  compliance. 

•  Initiate  an  objective  assessment  of  what  the  ERP  programs  can  realistically 
deliver. 

•  Create  an  open  environment  where  leaders  are  equally  rewarded  for  program 
cancellations  and  for  continuing  programs.  If  a  program  manager  has  the  courage  to 
recommend  changing  a  program’s  course  (e.g.,  pausing,  streamlining,  or  cancelling  a 
program),  careful  consideration  should  be  given  to  including  program  leadership  in 
decisions  regarding  how  funding  not  yet  expended  should  be  re-allocated. 

•  Implement  IT  solutions  that  address  the  entire  DOTMLPF  spectrum,  not  just 
one  particular  component  at  the  expense  of  another. 

•  Establish  an  environment  beyond  leadership  and  demand  an  era  of  stewardship 
as  the  baseline  for  managing  the  Department’s  IT  investments. 

All  oversight  and  reviews  of  MAIS  business  programs  should  be  coordinated  and  streamlined 
through  the  OSD  and  MilDep  DCMOs  using  the  IRBs  and  in  accordance  with  the  Business 
Capability  Lifecycle14. 

•  The  MilDep  DCMOs  should  provide  the  business  portfolio  view  and  collective 
position  of  the  Service  to  the  OSD  DCMO.  The  MilDep  DCMOs  must  also  serve 
as  the  Chief  Collaboration  Officers  between  their  MilDep  and  sister  Services  to 
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USD  (AT&L)  memo  of  15  Nov  2010,  Interim  Acquisition  Guidance  for  Defense  Business  Systems  (DBS) 
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ensure  best  practices  are  leveraged  and  the  best  of  the  DoD’s  IT  investments  are 
brought  forward  for  the  benefit  of  the  whole  DoD. 


•  The  MilDep  DCMOs  should  be  empowered  with  the  authority  and  responsibility 
for  establishing  the  strategy  and  execution  of  business  modernization  for  their 
Department.  This  should  include  the  systems  and  ancillary  resources  associated 
with  these  programs. 
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Appendix  A.  ERP  and  DoD  Business  Systems 


A.l.  Why  ERP? 

Enterprise  Resource  Planning  (ERP)  systems  are  large,  commercial-off-the-shelf  (COTS) 
packages  that  are  designed  to  contain  the  primary  components  of  the  business  operations 
of  an  organization.  The  primary  value  proposition  for  implementing  ERP  systems  is  that 
most  aspects  of  a  business  can  be  managed  as  an  integrated  solution.  This  makes  it 
possible  to  avoid  many  of  the  most  intractable  problems  that  plague  organizations  such 
as: 

•  Multiple,  conflicting  representations  of  the  same  data  becomes  a  single  version  of 
the  “truth;” 

•  Inefficient  business  processes  that  evolved  over  time  optimized  to  individual  parts 
of  the  business  and  not  the  larger  enterprise; 

•  Expensive  and  error  prone  integration  of  stand-alone  software  packages  requiring 
extensive  manual  intervention  and  reconciliation;  and 

•  Lack  of  visibility  to  senior  managers  of  the  current  state  of  the  organization’s 
business  operations  in  order  to  make  important  decisions. 

ERP  systems  contain  leading  practice  representations  of  business  processes  that  have,  in 
most  cases,  been  tested  in  large  numbers  of  organizations.  The  business  processes  in  an 
ERP  may  be  configured  in  many  variations  in  order  to  allow  them  to  suit  a  large  number 
of  organizations  and  industries.  Both  SAP  and  Oracle  ERP  systems  have  underlying, 
pre-defined  sets  of  capabilities/activities  and  processes.  SAP  in  particular  provides 
‘Solution  Maps’  including  some  that  are  tailored  for  the  Department  of  Defense. 
Processes  are  configurable  so  that  tasks/steps  can  be  added  to  or  removed  from  a  process. 
Configuring  an  SAP  or  Oracle  system  requires  knowledge  of: 

1)  The  organization’s  processes, 

2)  The  process  as  implemented  in  the  COTS/ERP, 

3)  An  understanding  of  the  difference, 

4)  And,  most  importantly  the  differences  that  are  tolerable. 

The  typical  way  to  deal  with  the  ‘intolerable’  elements  of  the  process  is  to  customize 
through  RICE  (Report,  Interface,  Conversion,  and  Enhancement)  objects.  Interface, 
conversion  and  enhancements  must  be  carefully  evaluated  and  prioritized  as  they  can  be 
particularly  costly  and  in  some  cases  not  feasible. 
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A.1.1.  Necessary  Conditions  for  Successfully  Using  ERP 


When  industry  began  using  integrated  software  solutions  in  the  1980s,  many 
organizations  attempted  to  adapt  the  software  to  their  specific  businesses  processes 
through  customization.  Few  of  these  efforts  were  successful  and  most  were  failures.  It 
became  apparent  that  in  order  to  successfully  use  COTS  solutions,  organizations  had  to 
accept  minimal  or  no  customization  of  the  software. 

If  an  organization  accepts  minimum  customization  as  a  major  premise,  the  inevitable  next 
hurdle  is  that  the  organization  fielding  a  COTS  solution  must  change  their  business 
operations  to  align  to  the  capability  of  the  ERP.  To  build  congruency  between  what  the 
software  will  allow  and  the  construct  of  the  business  as  it  exists  in  the  present  state,  often 
extensive  changes  are  required  including  processes,  job  roles  and  responsibilities,  and 
organizational  structures.  Throughout  this  change  a  senior  executive  level  sponsorship  is 
a  factor  critical  to  success. 

Industry  implementations  indicate  that  large-scale  enterprise-level  ERP  implementations 
are  only  successful  when  they  have  active  and  engaged  sponsorship  from  a  senior 
executive.  This  usually  means  the  level  of  CEO  or  COO  (for  example,  IBM’s  business 
transformation  was  led  by  Lou  Gerstner  and  his  deputy  in  the  1990s)  or  someone  who  has 
broad  authority  to  make  changes  to  the  business  processes  and  accountability  for  the 
success  of  the  program.  Engaged  sponsorship  in  this  context  means  that  the  senior 
champion  has  the  authority  and  willingness  to  exercise  the  authority  to  enforce  all 
necessary  changes  to  the  business  required  for  successful  fielding  of  the  software. 

Supporting  ERP  implementation  is  a  significant  component  of  the  sponsor’s  job  requiring 
engagement  on  a  weekly  or  even  daily  basis.  Attendance  at  a  monthly  or  quarterly 
steering  committee  meeting  is  not  sufficient.  If  a  sponsor  meeting  these  criteria  at  the 
enterprise  level  is  not  possible,  scoping  the  implementation  to  a  smaller  operating  unit  of 
the  business  where  that  level  of  sponsorship  can  be  achieved  can  still  have  an  successful 
ERP.  For  example,  if  it  is  impractical  to  have  the  Undersecretary  or  the  Vice  Chief  acting 
in  the  sponsor  role  for  a  Service,  then  scoping  an  ERP  to  a  major  command  and  having 
that  commander  be  the  sponsor  is  a  viable  alternative.  The  needs  of  the  enterprise  would 
then  have  to  be  met  through  the  enforcement  of  enterprise  data  standards  and  roll-up  of 
data  from  several  ERP  systems. 

A.2.  ERP  Global  Single  Instance 

Industry  experience  has  proven  that  it  is  almost  impossible  to  field  a  global  single 
instance  of  ERP  software  to  a  very  large  organization  (Fortune  500).  Several  programs 
that  have  tried  to  do  so  have  achieved  notoriety  for  the  challenges  that  they  faced, 
perhaps  most  notably  Hershey  and  DuPont.  In  Fortune  500  companies,  most  have  fielded 
multiple  ERPs  or  multiple  instance  of  an  ERP  where  each  business  unit  has  an  instance  of 
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the  ERP.  Many  of  the  companies  that  took  this  approach  are  now  beginning  to 
consolidate  these  into  fewer  ERPs  where  there  is  a  business  case  to  do  so 

A.3.  History  of  ERP  Not  Meeting  Expectations 

The  challenges  the  Services  have  faced  in  implementing  ERP  are  similar  to  those  that 
industry  has  faced.  Statistics  show  that  many  or  even  most  ERP  programs  in  industry  are 
challenged,  showing  cost  and  schedule  growth  or  failure  to  achieve  many  of  the  benefits 
anticipated  in  their  business  cases.  Industry,  however,  benefits  from  much  clearer  lines  of 
accountability,  business  metrics  (profit  and  loss)  and  real  limitations  on  how  much  the 
budget  for  a  program  can  expand.  These  factors  ensure  that  industry  faces  up  to  its 
challenges  and  failures  early  in  the  process  resulting  in  major  course  corrections  when 
necessary  or  early  program  termination. 

A.4.  Quick  Look  at  Service  ERPs 

The  following  sections  are  a  synopsis  of  the  major  Service  ERP  systems  by  Service  and 
then  acquisition  program. 

A.4.1  Army  ERP  Acquisition  Programs 

a)  Programs  and  Status 

•  GFEBS:  partially  fielded 

•  GCSS-Army:  in  operational  testing 

•  LMP:  approaching  full  operating  capability 

All  three  of  these  Anny  programs  are  based  on  different  versions  of  SAP. 

b)  Key  Foundational  Issues 

The  original  strategy  of  GFEBS  was  to  capture  all  detailed  transactions  from  the  source 
systems  that  generated  them  and  to  become  the  system  of  record  for  all  of  those 
transactions.  This  strategy  did  not  account  for  the  fact  that: 

•  Transaction  volume  across  interfaces  between  GFEBS  and  both  GCSS-Army  and 
LMP  would  require  scalability  beyond  predictions  and  the  level  of  reconciliation 
and  manual  intervention  required  to  ensure  transaction  integrity  would  not  be 
feasible 

•  Three-way  match  of  orders,  receipts  and  payments  required  for  auditablilty  would 
be  fragmented  across  multiple  systems  and  unlikely  to  be  achieved 

•  Design  choices  between  GCSS-Army,  LMP  and  GFEBS  would  make  it 
impossible  to  achieve  cost  accounting  goals  (activity  based  costing)  consistently 
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•  Despite  GFEBS  nominal  status  as  system  of  record  for  all  accounting 

transactions,  the  underlying  source  systems  could  still  modify  the  originating 
transactions 

GCSS-Army  and  LMP  were  both  conceived  as  logistics  systems  and  their  original 
designs  did  not  address  many  of  the  factors  required  to  achieve  auditability. 

GCSS-Army  is  implemented  utilizing  the  Defense  Force  Public  Security  (DFPS) 
capability  of  SAP  while  LMP  and  GFEBS  are  not. 

c)  How  the  Issues  Have  Been  Addressed 

The  Army  was  required  by  the  milestone  decision  authority  at  the  GFEBS  and  GCSS- 
Army  MS  B  decisions  to  create  an  ERP  strategy  to  address  the  issues  discussed  above. 
The  outcome  was  a  decision  to  re-scope  both  GFEBS  and  GCSS-Army  allowing  GCSS- 
Army  to  manage  all  tactical  logistics  general  fund  transactions  using  a  design  based  upon 
the  GFEBS  blueprint.  GCSS-Army  would  operate  a  subsidiary  ledger  and  post 
summaries  of  the  GFEBS.  GCSS-Army  became  the  target  system  of  record  for  general 
fund  transactions  generated  by  the  execution  of  tactical  logistics  in  the  Army. 

LMP  was  not  re-scoped  at  that  time  and  problems  such  as  transaction  integrity  across 
system  boundaries  and  ability  to  implement  the  three-way  match  remain.  LMP  is  now 
intended  to  be  the  Army’s  system  of  record  for  the  Working  Capital  Fund  and  a  major 
source  of  General  Fund  transactions  although  it  was  not  initially  intended  to  be  a 
complete  accounting  system.  It  will  likely  require  a  major  upgrade  or  re-implementation 
of  LMP  to  allow  it  to  fully  achieve  its  current  role  in  Army  financial  improvement.  A 
significant  complication  is  the  unusual  ownership  rights  the  Computer  Science 
Corporation  (CSC)  has  for  the  intellectual  property  of  the  LMP  system. 

The  Army  is  currently  working  on  a  new  ERP  strategy  at  the  request  of  the  Combined 
IRB  for  Acquisition;  however  it  is  unclear  how  this  can  be  meaningfully  achieved  given 
the  lack  of  an  overarching  Army  strategy  for  the  business  modernization  that  includes 
financial  improvement  and  auditability. 

IDA  is  unaware  of  any  effort  that  has  been  done  to  correct  the  limitations  that  the  existing 
ERP  design  will  place  on  the  Army’s  ability  to  implement  activity  based  costing  and 
other  cost  accounting  capability. 

A.4.2  Air  Force  ERP  Acquisition  Programs 

a)  Programs  and  Status 

•  DEAMS  -  partially  fielded  to  USTRANSCOM  at  Scott  AFB,  post  MS-A  for 
larger  AF 

•  ECSS  -  post  MS  B 
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DEAMS  and  ECSS  are  based  on  ORACLE  eBusiness  suite. 


b)  Key  Foundational  Issues 

DEAMS  original  strategy  was  to  capture  all  detailed  transactions  from  the  source  systems 
that  generated  them  and  become  the  system  of  record  for  all  of  those  transactions.  This 
strategy  did  not  account  for  the  fact  that: 

•  Transaction  volume  across  interfaces  between  DEAMS  and  ECSS  would  be  of  a 
larger  scale  than  predicted  and  the  level  of  reconciliation  and  manual  intervention 
required  to  ensure  transaction  integrity  would  not  be  feasible 

•  The  three-way  match  required  for  auditability  (orders,  receipts  and  payments) 
would  be  at  risk  because  of  fragmentation  across  multiple  systems 

DEAMS  was  originally  constrained  by  a  directive  to  operate  in  such  a  way  as  to  allow  the 
legacy  systems  to  remain  the  systems  of  record  until  the  ERP  was  proven  to  be  effective 
and  to  “do  no  harm”  in  interfacing  to  legacy  systems,  meaning  that  no  modifications  to 
persisting  legacy  systems  were  allowed.  The  ERP  was  required  to  only  use  existing 
legacy  interfaces.  These  constraints  caused  the  violation  of  two  of  the  fundamental 
leading  practices  of  ERP  implementation,  namely  to  severely  limit  the  number  of 
customizations,  such  as  RICE  objects,  and  to  re-engineer  business  processes  rather  than 
modifying  the  ERP  to  reflect  existing  business  processes. 

ECSS  was  conceived  as  a  logistics  system  and  was  originally  only  intended  to  implement 
functionality  to  address  the  working  capital  fund.  It  was  intended  that  that  ECSS  would 
interface  with  DEAMS  for  all  general  fund  transactions. 

ECSS  was  initially  intended  to  be  a  combination  of  three  COTS  products,  ORACLE  R12 
eBusiness  suite,  IFS  and  Click.  It  became  apparent,  approximately  a  year  into  the 
blueprinting  process,  that  the  combination  of  products  was  not  as  integrated  as 
represented  by  the  vendors  and  would  not  meet  the  needs  of  the  Air  Force  without  a 
significant  change  in  direction. 

ECSS  currently  claims  to  be  the  largest  ERP  program  in  history.  The  program  currently 
has  close  to  1000  staff  members.  ECSS  has  experienced  execution  challenges  as  a  result 
of  the  sheer  size  of  the  program. 

Both  DEAMS  and  ECSS  have  suffered  from  a  lack  of  effective  cross-functional 
governance  and  a  cumbersome  acquisition  governance  chain. 

Both  ECSS  and  DEAMS  have  reported  that  they  are  unable  to  meet  the  statutory 
requirements  for  time-certain  development. 
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c)  How  the  Issues  Have  Been  Addressed 

The  Army  decision  to  re-scope  both  GFEBS  and  GCSS-Army  to  allow  GCSS-Army  to 
manage  all  tactical  logistics  general  fund  transactions  using  a  design  based  upon  the 
GFEBS  blueprint  led  to  a  similar  strategy  for  DEAMS  and  ECSS.  The  details  of  how  this 
will  be  accomplished  and  the  precise  scope  of  what  aspects  of  financial  management  each 
program  will  implement  remain  unclear  below  the  level  of  executive  briefings. 

The  ECSS  program  was  restructured  and  the  IFS  and  Click  product  components  of  the 
software  suite  abandoned  in  favor  of  the  upgraded  Oracle  R12  eBusiness  suite  and  a 
commitment  from  Oracle  Corporation  to  provide  the  necessary  complex  maintenance 
capability  in  a  future  release.  The  program  was  restructured  from  three  to  four  releases  to 
facilitate  this  transition.  The  most  important  capability,  flight-line  maintenance,  is 
deferred  to  the  fourth  and  final  release. 

ECSS  remains  an  immense  ERP  program  and,  if  it  works,  will  be  far  larger  than  any 
ever-attempted  in  Industry.  There  is  no  history  of  success  for  ERP  programs  this  large 
and  many  data  points  for  failure  when  it  has  been  attempted.  After  more  than  5  years  and 
in  excess  of  $500  million  expended,  the  program  has  yet  to  declare  a  baseline  for  cost  and 
schedule. 

The  Air  Force  has  realigned  the  acquisition  reporting  chains  for  both  ECSS  and  DEAMS, 
naming  General  Officers  as  Program  Executive  Officers  (PEO)  for  each  program.  In  the 
case  of  ECSS,  the  PEO  and  Program  Manager  responsibilities  are  combined. 

A.4.3  Navy  ERP  Acquisition  Programs 

a)  Programs  and  Status 

•  Navy  ERP  is  fielded  to  NAVAIR,  SPAWAR  and  NAVSUP  systems 
commands,  currently  rolling  out  to  NAVSEA 

•  Navy  ERP  is  based  on  SAP 

b)  Key  Foundational  Issues 

The  original  vision  of  the  Navy  ERP  was  a  logistics  system  that  would  manage  all  of  the 
Navy’s  logistics  operations  both  afloat  and  ashore.  The  Navy  ERP  program  has  evolved 
into  more  of  a  financial  system  than  a  logistics  system.  The  current  scope  of  the  Navy 
ERP  includes  only  financial  management  and  supply  for  the  four  Navy  System 
Commands  listed  above. 

The  Navy  ERP,  like  all  of  the  other  Service  ERPs,  is  fragmented  by  the  mandate  to  use 
several  external  systems.  In  the  case  of  Navy  ERP,  significant  problems  arose  in 
attempting  to  implement  the  3-way  match  of  order,  receipt  and  payment.  This  was  a 
result  of  inconsistencies  between  how  accounting  data  was  represented  and  preserved  in 
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moving  between  Navy  ERP  and  the  Standard  Procurement  System  (SPS),  Wide  Area 
Work  Flow  (WAWF),  Accounting  Prevalidation  Module  (APVM),  Mechanization  of 
Contract  Administration  System  (MOCAS)  and  other  external  systems. 

The  result  was  large  numbers  of  unmatched  disbursements  and  a  significant  level  of 
manual  intervention  and  reconciliation  required. 

c)  How  the  Issues  Have  Been  Addressed 

The  Navy  ERP  resorted  to  custom  automation  and  several  other  workarounds  in  order  to 
achieve  acceptable  levels  of  perfonnance  in  executing  the  procure-to-pay  process.  It 
remains  unclear  that  the  auditability  goals  of  the  Navy  can  be  fully  achieved  until  the 
system  is  used  to  implement  the  process  from  end  to  end,  without  compromising  the 
integration  through  the  use  of  external  DoD  Enterprise  systems. 

The  Navy  removed  intennediate  level  maintenance  capability  from  the  scope  of  the 
program  which  required  it  to  report  a  breach  of  perfonnance  to  Congress  under  the  MAIS 
statutory  requirements. 
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Appendix  B.  ERP:  Efficiencies  Realized  and  Unrealized 

across  Cost  and  Time 


ERP  software  solutions  vary  in  implementation  but  have  a  similar  goal-to  optimize 
business  process  efficiency  through  automation  and  integration.  In  the  fifty  or  so  years 
that  computers  have  been  available  to  the  commercial  world,  businesses  have  automated 
more  and  more  of  their  procedures.  While  early  computers  introduced  shortly  after  World 
War  II  were  mainly  used  to  compute  mathematical  and  statistical  solutions,  serious 
commercial  use  began  in  the  late  1950s  for  financial  management  in  banks  and  insurance 
companies.  In  the  early  1960s,  the  first  computerized  airline  reservation  systems  were 
developed.  At  about  the  same  time,  computers  were  beginning  to  be  used  for  designing 
manufactured  goods  and  by  the  mid-1960s  were  being  proposed  to  control  manufacturing 
processes.  By  the  mid-1970s,  computer  aided  design  and  manufacturing  (CAD/CAM) 
was  routine.  The  1970s  also  saw  the  first  computerization  of  personnel  management  as 
well  as  integrated  suites  of  Billing,  Inventory  Control,  Accounts  Receivable,  &  Sales 
Analysis  (BICARSA)  applications  for  construction,  distribution,  and  manufacturing. 

The  precursors  in  the  manufacturing  world  to  the  present-day  ERP  systems  were 
originally  know  as  Materials  Requirements  Planning  (MRP)  and  subsequently  as 
Manufacturing  Resource  Planning  (MRP  II)  systems.  These  systems  attempted  to  gain 
efficiencies  in  manufacturing  by  reducing  order  lead  times  while  maintaining  minimal 
inventory  and  maximizing  equipment  utilization.  MRP  II  systems  also  integrated 
financials  so  that  invoices  for  materials  ordered  could  be  paid  and  receipts  for 
manufactured  goods  could  be  tracked.  This  convergence  presaged  the  eventual  goal  of 
bringing  all  aspects  of  a  business  under  integrated  control  to  eliminate  redundancies  and 
errors  in  data  entry,  storage,  and  manipulation. 

It  was  not  until  the  1990s  that  business  software  suites  began  to  integrate  personnel 
functions,  payroll,  customer  contact,  sales  management,  and  shipping  into  the  purchasing, 
inventory,  production,  and  distribution  programs  of  the  1980s.  Further  innovations  began 
in  the  year  2000  with  internet-enabled  functions  and  e-commerce  being  added  to  the 
capabilities  of  ERP  suites. 

Today’s  ERP  systems  are  designed  to  integrate  all  automatable  aspects  of  an  enterprise, 
and  even  coordinate  information  exchange  among  an  enterprise’s  suppliers  and 
customers.  Although  such  seamless  integration  is  theoretically  feasible,  in  practice  there 
are  many  stumbling  blocks  to  successful  ERP  implementation.  The  biggest  hurdle  for 
organizations  is  managing  the  conversion  from  existing  practices  and  records  to  the 
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integrated  functions  enabled  by  the  adopted  ERP  system.  It  is  typical  for  an  organization 
to  have  multiple  records  of  what  amounts  to  the  same  information.  For  example, 
individual  personnel  can  be  recorded  in  a  payroll  system,  a  telephone  list,  a  travel  system, 
an  achievement  tracking  system,  a  promotion  system,  and  a  management  hierarchy,  as 
well  as  within  project  and  task  assignments;  a  single  part  on  a  shelf  can  be  identified  by 
the  process  that  acquires  it,  by  a  cross-reference  system  that  shows  substitutes,  and  also 
by  the  manufacturing  or  repair  processes  that  may  require  it. 

When  an  organization  brings  in  an  ERP  system,  it  faces  a  considerable  challenge  to 
merge  and  cleanse  its  many  redundant,  and  often  inconsistent,  records.  This  restriction  on 
data  can  cause  perturbations  of  procedures.  For  example,  a  manager  who  customarily 
provides  employee  reviews  as  qualitative  prose  may  have  to  adapt  to  the  new  career 
tracking  system  that  requires  rank  ordering  in  order  to  allocate  payroll  raises.  When 
properly  implemented,  ERP  systems  offer  the  ability  to  continuously  monitor  the 
financial  picture  of  an  enterprise,  not  only  from  invoices  and  receivables,  but  also  from 
capital  assets,  depreciation,  and  liabilities,  even  across  geographic  regions  and 
international  monetary  systems.  This  makes  an  organization  auditable,  simplifies  tax 
filings,  and  facilitates  adherence  to  generally  accepted  accounting  principles  (GAAP). 

Each  enterprise  must  decide  upon  the  scope  of  its  intended  implementation  because  there 
is  no  fixed  limit  to  the  facets  of  an  enterprise  that  can  be  captured  by  an  ERP  system. 
ERP  software  vendors  sell  modules  of  function  that  capture  different  aspects  of  a 
business’s  procedures,  and  the  user  must  decide  not  only  which  modules  are  appropriate 
but  also  how  deep  the  adoption  must  be  to  achieve  an  acceptable  return  on  investment.  If 
certain  existing  procedures  are  too  costly  to  change  or  replace,  can  the  ERP  system  be 
adequately  tailored  to  co-exist  with  them?  Companies  known  as  system  integrators  have 
become  the  purveyors  and  implementers  for  ERP  software  packages. 

Since  it  is  generally  not  possible  to  simply  license  ERP  modules  and  begin  to  use  them 
verbatim,  system  integrators  are  hired  to  examine  an  organization’s  existing  procedures 
and  to  detennine  how  many  can  be  adjusted  to  suit  the  ERP,  and  how  many  are 
immutable  and  will  instead  require  modifications  or  extensions  to  the  ERP.  It  takes 
considerable  will  on  the  part  of  an  adopting  organization  to  abandon  legacy  processes 
that  are  not  compatible  with  the  new  way  of  doing  business,  but  the  alternative  is 
additional  expense  to  build  and  maintain  the  bridges  between  legacy  data  and  the  new 
software. 

These  bridge  programs  are  known  as  RICE  objects,  for  the  reports,  interfaces, 
conversions,  and  extensions  that  may  be  needed  to  mesh  the  old  and  new  worlds  of  an 
adopting  enterprise.  It  is  reasonable  to  compromise  on  a  small  number  of  RICE  objects  to 
serve  as  the  scaffolding  to  enable  the  ERP  software  to  achieve  its  results.  However, 
because  of  the  separate  maintenance  required  to  keep  RICE  objects  up-to-date  with 
changes — not  only  to  the  outside  world,  but  also  to  upgrades  within  the  ERP  product— 
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there  are  diminishing  returns  for  the  cost  effectiveness  of  adopting  ERP  with  each 
additional  RICE  object.  An  organization  that  decides  to  implement  more  than  a  few 
dozen  RICE  objects  may  be  surprised  by  the  difficulties  that  ensue. 

B.l.  Overall  ERP  Implementation  Cost  in  the  DoD 

As  in  the  commercial  world,  ERP  efforts  in  the  DoD  vary  greatly  in  scope  and  cost  but  all 
must  achieve  the  same  basic  milestones  to  be  successful:  organizational  buy-in,  defined 
relationship  to  legacy  systems  and  processes,  rationalization  and  conversion  of  data,  and 
transition.  ERP  implementations  and  ERP-like  developments  in  DoD  range  from  the 
modest  Global  Exchange  (GEX)  system  that  normalizes  business  data  across 
communities,  at  a  continuing  sustainment  cost  of  $4M/yr,  to  GCSS-Army  and  ECSS-Air 
Force,  for  which  each  planning  development  costs  $200-300M/yr  for  the  foreseeable 
future.  The  past  nine  budgets  (FY2003-FY201 1)  show  the  numbers  of  DoD  ERP  system 
developments  doubling  (7  to  14)  but  with  average  total  budgets  for  each  increasing  over 
that  period  from  $100M  to  $645M.  Existing  programs  have  grown  and  new,  larger 
programs  have  been  added  since  2003.  The  net  effect  is  that  DoD  is  now  spending  $1.3B 
per  year  on  ERP  development,  and  over  the  FYDP  the  total  DoD  expenditure  budgeted 
for  ERP  systems  has  increased  more  than  ten-fold  from  $700M  to  $9B,  as  shown  in  Table 
B-l. 


Table  B-1.  ERP  Cost  Increase  Over  Time 


#Sys 

AvSys  $M 

$M/Sys/Yr 

$M/Yr 

Total  $B 

FY03 

7 

103 

13 

90 

0.7 

FY04 

7 

401 

50 

351 

2.8 

FY05 

9 

494 

62 

555 

4.4 

FY06 

12 

516 

64 

774 

6.2 

FY07 

13 

470 

67 

872 

6.1 

FY08 

13 

572 

72 

930 

7.4 

FY09 

14 

528 

66 

923 

7.4 

FY10 

13 

733 

105 

1,362 

9.5 

FY11 

14 

645 

92 

1,289 

9.0 

While  the  perceived  procurement  costs  of  these  systems  has  increased  to  an  average  of 
over  $600M,  with  the  highest  cost  systems  adding  over  $1.5B  each  to  the  FYDP,  there 
may  still  be  a  positive  return  on  these  investments.  Corporate  investments  in  large  ERP 
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implementations  routinely  top  $1B.  However,  corporate  environments  do  not  face  many 
of  the  unusual  impediments  found  within  DoD.  Moreover,  the  return  on  industry 
investments  in  the  form  of  reduced  process  costs,  lower  inventories,  faster  turns,  and 
higher  market  agility,  are  visible  and  directly  benefit  a  corporate  bottom  line.  The  DoD 
environment,  in  contrast,  is  not  as  well  suited  to  ERP  tools  and  the  profitability  incentives 
are  not  comparable.  Although  Congress  has  long  demanded  that  the  Services  achieve 
auditability,  the  main  mission  of  the  MILDEPS  is  defense,  which  relies  more  on  logistics 
than  accounting.  ERP  vendors  and  system  integrators  who  have  experience  with 
commercial  environments  find  that  the  tools  are  not  designed  for  the  DoD  environment, 
and  a  great  deal  of  effort  has  been  expended  both  on  the  part  of  system  integrators  and 
tool  vendors  to  force  these  marriages. 

The  FYDP  budget  does  not  give  a  full  picture  of  the  development  cost  of  these  systems, 
and  many  of  the  larger  ERP  implementation  programs  will  not  produce  results  that  will 
justify  their  cost.  Indeed,  many  have  spent-and-will  continue  to  spend-millions  or  even 
billions  with  little  tangible  benefit  evidenced  or  resulting  in  a  cancellation  (e.g., 
DIMHRS).  To  date,  the  best  ERP  example  implementations  in  the  DoD  are  of  limited 
scope  in  both  number  of  organizations  and  in  function  while  the  larger,  overarching 
implementations  remain  in  doubt  (ECSS,  GCSS-Army,  and  Navy  ERP). 

IDA  estimates  of  the  cost  of  implementing  large-scale  ERP  in  DoD  environments 
(personnel,  financial,  and  logistics)  have  been  forced  to  provide  exceptionally  wide  error 
bounds  due  to  the  extreme  uncertainties.  A  broad  set  of  factors  including  legislation, 
culture,  priorities,  mission,  continuity,  motivation,  and  DoD  adoption  of  commercial 
approaches  to  management  is  fraught  with  complexity,  special  cases,  exceptions, 
incompatibilities,  and  limitations  that  makes  estimation  virtually  open-ended.  Even  the 
best-case  estimates  of  cost,  estimates  that  assume  that  organizations  can  agree  on  data 
definitions,  ownership,  business  processes,  and  priorities,  hover  around  $1  billion  for  a 
DoD  organization  (service  arm  or  agency).  The  probability  of  failing  to  achieve 
conformity,  and  therefore  of  exceeding  those  estimates,  is  high. 

Figures  B-l  through  B-5  show  various  ERP  systems  cost  growth  over  time. 
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Figure  B-1.  ERP  Acquisition  Costs  (BY11  $M) 


Figure  B-2.  GFEBS  Acquisition  Costs  (BY11  $M) 
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Figure  B-3.  GCSS-Army  Acquisition  Costs  (BY11  $M) 


Figure  B-4.  DEAMS-AF  Acquisition  Costs  (BY11  $M) 
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Figure  B-5.  DIHMRS  Acquisition  Costs  (BY11  $M) 
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Appendix  C.  Capability  and  Assessments 


The  overlap  in  capabilities  across  the  ERP  systems  was  analyzed  by  a  review  of  the  DoD 
IT  Portfolio  Repository  (DITPR)  reports  for  each  of  the  ERP  systems  listed  in  the 
following  tables.  The  DITPR  reports  contained  tables  with: 

Capabilities 

System  functions 

Processes 


The  capabilities  listed  for  each  ERP  in  the  DITPR  are  the  same  as  the  high-level  activities 
in  the  Business  Enterprise  Architecture  (BEA)  activity  model.  In  other  words,  the 
Components  considered  the  high-level  activities  to  be  equal  to  capabilities  for  the 
purpose  of  the  DITPR.  The  lower-level  and  more  granular  BEA  operational  activities 
were  mapped  to  the  newly  created  capabilities,  so,  in  effect,  the  lower-level  operational 
activities  are  a  decomposition  of  each  capability.  Each  capability  therefore  has  a  set  of 
activities  that  may  be  performed  in  order  to  accomplish  the  capability. 

The  overlap  in  capabilities  for  each  ERP  is  graphically  depicted  in  table  form  in  Table  C- 
1 .  This  table  depicts  the  capabilities  in  the  rows,  and  the  systems  that  have  that  capability 
in  the  columns.  The  shaded  cells  indicate  that  the  system  in  that  column  has  the 
capability.  The  table  also  shows  the  total  number  of  capabilities  for  each  system. 

Table  C-1.  BEA  Capabilities 

BEA  Capabilities 

(32  of  36  implemented  by  these  ERP  systems) 


FinancialReporting 

ManageGeneralLedger 

ManageFinancialAssetsandLiabilities 

ManagePayment 

ManageReceiptandAcceptance 
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BEA  Capabilities 


(32  of  36  implemented  by  these  ERP  systems) 


CollectandDisburse 


Managerial  Accounting 


PerformAssetAccountability 


DisposeorReturnPropertyandMateriel 


PerformBuildandMakeandMaintenanceandSustainment 


ManageSourcing 


ForecastPlanProgramBudgetandFundsDistributionandControl 


RealPropertylnventory 


DeliverPropertyandForces 


ManageRequest 


EnvironmentalLiabilitiesidentificationandValuation 


ConductProgramManagement 


ManageAcquisitionOversightlntegration 


AccountingandFinance 


CorporateManagementandSupport 


Program/BudgetandPerformance 


ContractSupportlntegration 


NetCentric 


FacilitiesSupport 


Supply 


HazardousMaterialsProcessControlsandlnformationManagement 


ProgramBudgetandFinance 


RealPropertyAcceptance 


CapabilityTitleBEPStakeholder 
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BEA  Capabilities 

(32  of  36  implemented  by  these  ERP  systems) 

< 

o 

EBS 

DEAMS 

ECSS 

GCSS-Army 

GFEBS 

LMP 

NAVY-ERP 

GCSS-MC 

ManageSupplierNetworks 

Contracting 

ManageOrganization 

Grand  Total 

19 

1 

5 

14 

20 

16 

8 

10 

5 

At  a  capability  level,  it  appears  there  is  a  significant  amount  of  overlap,  but  as  mentioned 
previously,  the  capabilities  are  a  composition  of  smaller  and  more  granular  operational 
activities,  functions  and  processes.  So,  although  there  is  overlap  at  the  capability  level, 
the  process  or  function  being  applied  at  the  more  granular  level  should  reflect  the  unique 
business  processes  of  the  Service  or  Agency  and  would  not  necessarily  reflect 
unnecessary  redundancy.  See  Tables  C-3  and  C-4  for  BEA  functions  vs.  systems  and 
BEA  Processes  and  also  see  Table  G-l  for  the  Assessment  Framework. 

Figure  C-l  represents  the  DoD  capabilities  in  the  context  of  the  organizational 
units/groups  that  have  or  provide  the  capability.  The  current  BEA  does  not  document 
which  people  (org)  execute  processes  and  what  tools  they  use,  so  IDA  used  the  NY C  EA 
Framework  (NEAF)  to  create  the  context  needed  to  do  an  overlap  evaluation  of  the 
capabilities.  This  simple  mapping  of  organizational  units  to  the  processes  they  execute 
and  the  systems  used  in  executing  the  processes  (people,  processes,  and  tools)  could  be 
implemented  in  either  DITPR  or  the  BEA  to  highlight  the  cross-organizational  (NOT  IT) 
systems  issues  that  need  to  be  addressed.  This  mapping  could  also  help  to  identify  who 
has  Command  and  Control  over  all  the  affected  organizations  and  who  can/should 
enforce  standards  of  performance  for  a  given  process  or  function  (once  determined  that 
the  standard  is  desirable  based  on  an  organization’s  unique  requirements). 
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Figure  C-1.  Capabilities  by  Organizational  Unit 
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Table  C-2.  BEA  System  Functions 


BEA  SYSTEM  FUNCTIONS 

DEAMS/ECSS  have  no  System 
Functions  listed 


ManageBusinessEnterpriseReporting 


ManageData 


MaintainGeneralLedger 


ManageFunds 


ManageObligations 


ManageLiabilities 


ManageReceivables 


ManageCollections 


ManageCommitments 


ManageBilling 


ManageScheduled  Payments 


ManageProcurementlnformation 


ManageReceiptandAcceptance 


PrepareCertifiedBusinessPartnerPayment 


ManageRequirement 


ManageAgreementandContractandOrder 


ManageDisbursements 


ManageBuyerorSellerRegistrationlnformation 


ManageFederalTechnicalData 


ForecastCash 


GeneratePaymentNotification 


ManageElectronicCatalogandOrdering 


Managelnvestments 


ManageSolicitation 


to 

00 


to 

< 

to 

to 

LU 

u 

a 

LU 

>■ 

E 

S_ 

< 


tO 

CQ 


a. 

cc 

LU 

> 
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BEA  SYSTEM  FUNCTIONS 

DEAMS/ECSS  have  no  System 

Functions  listed 

BEIS 

DAI 

EBS 

DEAMS 

ECSS 

ManageSupplierEligibility 

ManageContractAward 

GetAIICurrentContracts 

ManageQualityControl 

DeliverlnformationProduct 

IdentifyReturnRequirement 

ExecuteReturnSchedule 

PerformBuildandMakeandMaintenanceand 

Sustainment 

PlanReturn 

ManageandTracklssues 

DistributeProducts 

ManageDisposal 

ManageFinanciallnformationStructure 

ProcessReturned  Materiel/Asset 

ManageCost 

PerformAssetAccountability 

ManageAssetRecord 

ManageAssetValuation 

CalculateSupplyChainEntitlement 

CreateReturnPlan 

ProcessOrderReturn 

ProvideOrderStatus 

PlanMaterielResources 

IdentifyResourceforActivities 

> 

E 

< 

■ 

to 

to 

u 

o 


to 

CQ 


a. 

cc 

LU 

i 
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GCSS-MC 


BEA  SYSTEM  FUNCTIONS 

DEAMS/ECSS  have  no  System 

Functions  listed 

BEIS 

DAI 

EBS 

DEAMS 

ECSS 

CreateMaterielResourcePlan 

ExecuteMaterielResourceSchedule 

IdentifyMateriel  Requirement 

AggregateSpend  Data 

ManageApportionmentandAllocation 

FormulateProgramandBudget 

Recordlnspection 

ProcessShipments 

RecordReceipt 

EstablishTransportationMovementRequirement 

ExecuteTransportationSchedule 

Package/Handle/TransportMaterial/Personnel 

T  rackT  ransportationStatus 

AcceptMateriel/PersonnelforTransportation 

CollectTransferDatafromExternalSource 

PerformBenefitsManagement 

ManageMissionSupportRequirements 

RecordTransportationFulfillment 

ProcessQualityofLifeBenefit 

PerformReporting 

PlanLogisticsServices 

ManageSupplierRepresentationandCertification 

ManageDelinquentDebt 

IdentifyReturnResource 

RetrieveltemStatusandAvailability 
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BEA  SYSTEM  FUNCTIONS 

DEAMS/ECSS  have  no  System 

Functions  listed 

BEIS 

DAI 

EBS 

DEAMS 

ECSS 

GCSS-Army 

GFEBS 

LMP 

Navy-ERP 

GCSS-MC 

FunctionTitleBEPStakeholder 

PerformCross-CuttingAnalysisandReporting 

DevelopLogisticsStrategicPIan 

DevelopIntegratedLogisticsPlan 

AssessDemand 

ManageandDevelopPlanCriteria 

AssessCapacity 

Perform  DataChecks 

PerformProgramAnalysis 

CT> 

rsi 

Recordlssuance 

CreateTransportationPlan 

IdentifyTransportationResource 

PlanDistribution 

Grand  Total 

m 

rsi 

o 

o 

cn 

VO 

fM 

m 

o 

VO 

tH 
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Table  C-3.  BEA  Processes 


BEA  Processes 


PostGeneralLedgerTra  reactions 


PerformFinancialReporting 


PosttoGeneralLedger 


CaptureProForma  Entries 


RequestGeneralLedgerCorrectingProForma 

Entries 


GenerateGeneralLedgerTransactions 


AnalyzeUnapprovedTrialBalance 


AnalyzeDraftPeriodEndorOnDemandFinancial 

Statement 


ApproveTrialBalance 


CreateNotificationforSourceoflncomplete 
Financial  Information 


PrepareFinalPeriodEndorOnDemand  Financial 
Statement 


RequestCollectandAnalyzelMarrativeandorFoot 

notelnformation 


CreateDraftPeriodEndorOnDemandFinancial 

Statement 


CreateFinancialStatementLevelAdjustment 


DocumentldentifiedCorrections 


CoordinateDraftPeriodEndorOn  Demand 
FinancialStatementtoAuditFunction 


PerformRequiredFinancialStatement 

Eliminations 


SendStatementsofAccountabilityor 

TransactionsorTrialBalancetoTreasury 


ConfirmGeneralLedgerClosingProForma 

Entries 
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BEA  Processes 


ConfirmGeneralLedgerCorrectingProForma 

Entries 


RequestGeneralLedgerClosingProForma 

Entries 


ProcessTitleBEPStakeholder 


ReceiveandValidateRequestforBilling 


MaintainAccountsPayableBalance 


UpdateReceivablelnformation 


Collect 


VerifyFundsAvailability 


EstablishAccountsPayable 


MaintainAccruedLiabilityBalance 


CaptureFinancialTransactionReport 


CertifyFunds 


PreparelnitialTrialBalance 


EstablishCustomerlnformation 


PrepareReimbursableBill 


EstablishFundsControl 


EstablishReceivable 


SendNotificationofBillingtoAccounts 
Receivable  Process 


ValidateCustomerlnformation 


VerifyAssetorExpensePostingAccounts 


CreateWriteOffPackage 


ManageLiabilities 


SchedulePayment 


ReceiveAccountsPayableSupporting 

Documentation 
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NAVY-ERP 


BEA  Processes 


ManageExecutionFundAccount 


RecordandManageReceivable 


ProcessCollectionVoucherandDeposit 


MonitorPayment 


PerformCollectionandDisbursement 


CalculateSupplyChainEntitlement 


ReconcileDisbursements 


PreparePaidDisbursementVoucher 


ManageExecutionwithTreasury 


EvaluateLiabilitylnformation 


GenerateAccruedPayrollLiabilityProForma 

Entries 


GenerateContingencyAccruedLiability 
ProForma  Entries 


GenerateFinalUnapprovedTrialBalance 


ConfirmBilling 


CreateAnomalyExplanation 


GenerateOffsettingLiabilityorReceivable 

ProFormaEntries 


GeneratePrePaymentProFormaEntries 


GenerateProFormaEntriesforAccountsPayable 


GenerateProFormaEntriesforAdjustmentsto 

UndeliveredOrders 


GenerateProFormaEntriesforBilledCollection 


SendRequestforBill 


CalculateAssociatedRevenue 


CaptureCollectionlnformation 


GenerateProFormaEntriesforPostCancel 

Payment 


S2 

LLI 

CO 
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BEA  Processes 
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to 

to 

to 

CQ 

to 

to 

LU 

u 

u 

LL 

LU 

CL 

§ 


GenerateProFormaEntriesforPreviously 

UnidentifiedBilledCollection 

GenerateProFormaEntriesforPreviously 

UnidentifiedRevenueCollection 

DetermineBillingRequirements 

GenerateProFormaEntriesforPreviously 

UnidentifiedUnbilledCollection 

GenerateProFormaEntriesforUnbilled 

Collection 

Re-CalculateNewAccountsPayableBalance 

GenerateProFormaEntriesforUnidentified 

Collection 

ApplyAccountsPayableOffset 

GenerateReceivableProForma  Entries 

GenerateUnearnedRevenueAccrued  Liability 
ProFormaEntries 

EvaluatePayableRequestlnformation 

IssueCreditMemo 

LiquidateOutstandingAccountsReceivable 

Balance 

LiquidateOutstandingLiabilityBalance 

ConvertUnitedStatesDollarEquivalentto 

Foreign  Equivalent 

GenerateProFormaEntriesforCancellationofan 

AccruedLiability 

GenerateProFormaEntriesforClearingAccount 

GenerateProFormaEntriesforRevenue 

Collections 

ConfirmlnterfundBilling 

InvestigateAnomalies 

EstablishContractFloldback 
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NAVY-ERP 


BEA  Processes 


ValidateReceiptlnformation 


ApplyCollection 


GenerateProFormaEntriesforContract 

Holdback 


ValidateOtherReceiptsInformation 


CancelPayable 


CalculateAdjustmenttoUndeliveredOrders 


CompareOutstandingAccountsReceivable 

Balance 


ReceiveAdjustmentforDeliveredOrdersand 

AccountsPayable 


AnalyzeUnidentifiedCollectionlnput 


GenerateDisbursementProFormaEntries 


ReceiveOtherReceipts 


GenerateProFormaEntriesforPreviously 

UnidentifiedClearingAccount 


ReceiveDebitVouchers 


ValidateReimbursableReceiptlnformation 


AnalyzeAuditComments 


ReceiveCollectionReceipts 


RejectRequestforBilling 


PrepareAdviceofCollection 


ValidateCashPaymentReceipts 


ValidateRefundReceiptlnformation 


MatchtoOutstandingLiabilityBalance 


GenerateOffsettingReceivableLiability 
ProForma  Entries 


PrepareCertifiedBusinessPartnerPayment 


ReconcileDeposits 


S2 
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CO 


CO 
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BEA  Processes 

BEIS 

InterpretTreasuryConfirmationData 

ValidateCancelPaymentRequestlnformation 

ReconcileReceiptAccountLedger 

CancelPayment 

AnalyzeAnomaly 

CaptureTreasuryConfirmationData 

GenerateCorrectingProFormaEntries 

GenerateProFormaEntriesforAdvance 

Received  Collection 

CreateElectronicFundTransferFile 

ManageSched  tiled  Payments 

GenerateProFormaEntriesforDepositAccount 

ResearchAdviceofCollectionlnformation 

ValidateReadytoPayFilelnformation 

ReceiveCashPaymentReceipts 

ReconcileProgramlnformation 

ResearchDebitVoucherlnformation 

CreateWireTransferFile 

DistributePayment 

ManageRetumedPayments 

MatchCheckNumbertotheVoucher 

ReceiveGoodsandServices 

PerformlnspectionandTestingandVerification 
for  OtherGoodsandServices 

FinalizeAcceptanceforOtherGoodsandServices 

PerformAcceptanceProceduresforOtherGoods 

andServices 

BEA  Processes 

BEIS 

AcceptGoodsandServices 

MatchObligatingDocumentAcceptanceand 

PaymentRequest 

FileDiscrepancyReport 

FileDiscrepancyReportforOtherGoodsand 

Services 

PerformCostAnalysis 

PerformlnspectionandTestingandVerification 

MatchPaymentRequestandObligating 

Document 

AcknowledgeGoodsTenderedandServices 

Rendered 

FinalizeAcceptance 

PerformAcceptanceProcedures 

ReceiveAuditReport 

MatchFundingStatus 

EstablishClPandorWIPAccount 

CreateCIPandorWIPAccount 

AnalyzeSpendlnformation 

ValidateAccountStructure 

AcknowledgeOtherGoodsandServices 

MatchAcceptanceandObligatingDocument 

GenerateComponentDebtProFormaEntries 

Generatelnterfund  Billing 

ReviewFundingRequest 

GenerateProFormaEntriesforPreviously 

UnidentifiedRefundofanAdvance 

GenerateCapitalLeaseLiabilityProForma 

Entries 

BEA  Processes 

BEIS 

CompareResultstoPerformanceMeasurement 

Criteria 

CaptureCostlnformation 

AnalyzeProposedAuditAdjustment 

AcceptApprovedlntragovernmentalOrder 

ConfirmReceiptofOperationandMaintenance 

Information 

DefineandValidateAssetDataRelationships 

DefineandValidateAssetDataStructure 

DefineAssetDataElements 

PopulateAssetDataElements 

AssignandGeneratellniqueldentifi  cation 

ReceiveProjectEvidence 

RequestAdditionalSupportingCollection 

Information 

PerformQualityAssuranceonAggregated 

Information 

GenerateSubsidyAccruedLiabilityProForma 

Entries 

ProcessAccruedSeveranceLiabilitylnformation 

ProcessFundedPayrollandBenefitsinformation 

CivilianandMilitary 

ReviewReprogrammingRequirements 

DetermineReprogrammingActions 

RequestCorrectingProFormaEntries 

GenerateProFormaEntriesforUndeposited 

Account 

GenerateProFormaEntriesforlnvestment 

Collection 

AcceptSignedAgreement 
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BEA  Processes 


GenerateCustodialLiabilityProFormaEntries 


IssueCancelPaymentNotice 


Relieved  PandorWIPAccount 


AssociateProjectldentificationtoAppropriate 

WIPAccount 


ConductlnspectionalkthroughExamination 

andVerificationofSyWstemOperation 


GenerateProFormaEntriesforDonation 


ConfirmReceiptofAcquisitionlnformation 


CreateManagementRepresentations 


RecordCIPandorWIPFinancialTransactions 


AssembleCertifiedFinancialStatementPackage 


PerformReprogrammingandTransfers 


DeterminelfCIPandorWIPAccountisRequired 


Updated  PandorWIPAccount 


GenerateProFormaEntriesforPreviously 

UnidentifiedlnvestmentCollection 


DetermineOtherValuationMethods 


CertifyDiscrepancies 


ReviewandCertifyFinancialStatement 


MonitorContractorOrder 


CloseoutContractorOrder 


DisseminateTreasuryCollectionConfirmation 

Data 


ApplyTrendingTechniques 


RespondtoDraftAgreement 


DocumentResultsof  Reconciliation 


IdentifyAgreement 


to 
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BEA  Processes 


ConfirmContractorOrderPhysicallyComplete 


ReturnCancelPaymentRequest 


ArchiveOrder 


DetermineFinalCosts 


DisseminateTreasuryDisbursementConfirmati 
on  Data 


ReconcileUndisbursedExpenditureAccount 

Ledger 


MonitorAgreement 


ReleaseApprovedandorCertifiedFinancial 

Statements 


ReleaseFinancialStatements 


PopulateCostPerformanceModel 


DefineCostPerformanceModel 


ProcessRequirement 


NotifyCustomerCannotFulfillRequest 


ProcessCashPayment 


Verifylnformation 


CollectSpendlnformation 


ManageFinancialManagementPolicy 


IdentifyCapitalLeaseAssetAccountlnvolved 


DistributeProgramandFundingDocument 


DocumentModel  Results 


ApplyAnomalyDetectionCriteriatoData 


PerformlnternalReviewof  Model  Results 


ReviewForecastAnalysisRequest 


AllocatetoModelElement 


ExecuteAcceptanceTransactions 


S2 

LLI 

00 
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BEA  Processes 


ProcessAuthorizedPersonneland  Benefits 
Liability  Information 


ProcessFundedandllnfundedLeave 

Information 


SubmitApportionmentRequesttoOMB 


AssociateProjectldentificationtoAppropriate 

CIPAccount 


PrepareDepositTicketandAdviceofCollection 


ApplyChanges 


PrepareDoDApportionmentRequestfor 

Submission 


ConfirmReimbursableBill 


RequestContinuingResolutionActEstimates 


IdentifylnspectionandVerificationParticipants 


AnalyzeApportionment 


PrepareReportforCongressionalReview 


PrepareRequirementsforSubmissiontoOMB 


FormalizeContinuingResolutionActBaseline 


ManageBaselineforReprogramming 


ReviewAdditionalContinuingResolution 
Amount  Request 


AnalyzeAppropriationandGeneral  Provisions 


CaptureContinuingResolutionAdjusted 

Amount 


ManageReportof  Programs 


IncorporateChanges 


CaptureContinuingResolutionActEstimate 


IdentifyAcceptingOfficials 


ReviewRequestforReportofPrograms 
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BEA  Processes 


RecordTimeand  Attendance 


DevelopResponsetoCongressionalDecision 


IncorporateComments 


GenerateDisbursementlnTransitProForma 

Entries 


LiquidateOutstandingPenaltyAdministrative 
Fees  andlnterestBalance 


RejectAccountsReceivable 


PrepareScheduleofCancelledChecks 


PrepareTransferRequirementsforSubmission 
to  OMB 


CoordinateTransferRequirementswithOMB 


MaintainAccountsReceivableBalanceand 

Information 


SettheScopeoftheAnalysis 


MonitorandlmproveProcess 


ProcessIntraGovernmentalPaymentand 

Collection 


CoordinateReprogrammingRequirements 

withOMB 


PublishAnalytical  Results 


PublishBaseforProgramming 


CalculateAllowanceforLossonAccounts 

Receivable 


LiquidateOutstandingPrincipalBalance 


AnalyzeDeniedRequests 


Re-CalculateOutstandingPenalty 
Administrative  FeesandlnterestBalance 


ReferEligibleDebtstoTreasury 


ReviewTransferRequirements 
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BEA  Processes 


Re-CalculateOutstandingPrincipalBalance 


SelectExistingModel 


SelectTrendingTechniques 


SendBillingDocumenttoCustomer 


MaintainAccountsReceivableBalances 


ReviewOutstandingPrincipalBalance 


Re-CalculateReceivable 


UpdateReceivableAmount 


ProcessIntra-GovernmentalPayment 

andCollection 


Disburse 


AnalyzeReceivableRequest 


CaptureReceivableRequestlnformation 


GenerateProFormaEntriesforaRefundofAn 

Advance 


Calculatelnterest 


ReviewOutstandingPenaltyBalance 


LiquidatePenaltyBalance 


Re-CalculateAdministrativeBalance 


CalculatePenalty 


Re-CalculatePenaltyBalance 


GenerateDemandforPayment 


ReviewOutstandingDebtandOffsetRequest 


SendDemandForPaymenttoCustomer 


LiquidateAdministrativeBalance 


Re-CalculatelnterestBalance 


CalculateAdministrativeFees 


S2  — 

LU 
00 
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BEA  Processes 


CalculateAging 


CalculateAllowanceforLossonPublicReceivable 


ReviewOutstandinglnterestBalance 


SendDemandLetter 


LiquidatelnterestBalance 


RejectAccountsReceivableRequest 


EvaluateWhetherFurtherlnvestigationls 

Warranted 


EvaluateReport 


IdentifyAppropriationLineltemAmount 


RefertoLegal 


Liquidate  Principal  Balance 


Re-CalculatePrincipal  Balance 


NotifylVIanageDelinquentDebt 


ReclassifyContractFloldbacktoAccounts 

Payable 


RefertoTreasuryforCollection 


DeterminelfReceivableCanBeOffset 


GenerateDisbursementln- 

TransitProFormaEntries 


GenerateDunning 


CreateCheckPrintFile 


DisburseCash 


GenerateProFormEntriesforPreviously 

UnidentifiedDepositAccountCollection 


MaintainAssetlnformation 


ConductPhysical  Inventory 


CreatelnitialAssetRecord 


10 
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BEA  Processes 

BEIS 

DAI 

EBS 

DEAMS 

ECSS 

GCSS-Army 

UpdateAssetRecord 

ManageSalesand  Procurement 

AggregatelnitialAssetlnformation 

DevelopandUpdateWorkOrder 

DisposePropertyorMateriel 

AggregateAssetlnventoryCountResults 

AuthorizeWorkOrder 

ExecuteContract 

ExecuteSourcingStrategy 

AdministertheContract 

DeveloporModifyContractorOrder 

CompareForecastToActualPerformance 

ReviewAssetlnventoryCountResults 

ArchiveAssetRecord 

ValidateAssetDataElements 

Perform  AssetAccountability 

PerformAssetValuation 

CountAssets 

PerformRootCauseAnalysisandReform 

Inventory  ControlProcedures 

ApproveAssetlnventoryCountlnformation 

ConfirmReceiptofRegulatoryCompliance 

Information 

ProcessandSubmitValidatedEvidence 

IdentifyPropertyandMaterielforReturnor 

Disposal 

ScheduleReturnorDisposal 

to 
oo 

u-  ^ 
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NAVY-ERP 


BEA  Processes 

BEIS 

DAI 

EBS 

DEAMS 

ECSS 

GCSS-Army 

PerformBuildandMakeandMaintenanceand 

Sustainment 

AuthorizeReturnorDisposal 

PrepareDetailedScopeandCurrentWorking 

Estimate 

UpdateMilitaryEquipmentValuation 

CalculateBalanceComponentDebtHousing 

Preposition  Withdrawal 

RequestDesignApprovalPerMilestone 

DefineandRecord  Discrepancies 

ReviewCongressionalAction 

ConsolidateDiscrepancies 

TrackDeferralAccounts 

NegotiateOfferinCompromiseorProtest 

ConfirmReceiptofGraphicinformation 

GenerateEnvironmentalAccruedLiability 
ProForma  Entries 

ClassifyEnvironmental  Liability 

IncorporateCongressionalFeedback 

ReviewProposedDeferrals 

SchedulelnspectionsandVerifications 

ClassifyWork 

InterpretCongressional  Action 

CalculateNetlncreaseorDecrease 

RejectEnvironmentalLiabilitylnformation 

DefineWork 

ExecuteRescissionCancellationandDeferrals 

tO 

CO 


I 


a. 

cc 

LU 

I 

> 

> 

< 


u 


to 

to 

u 


C-25 


BEA  Processes 

BEIS 

DAI 

EBS 

DEAMS 

ECSS 

GCSS-Army 

GFEBS 

LMP 

NAVY-ERP 

GCSS-MC 

RelieveMilitaryEquipmentValuation 

GenerateReconciledDraftReport 

DevelopSourcingStrategy 

1 

DeveloporRefineSourcingPlan 

AwardContractorAcknowledgeOrderorlssue 

Modification 

NegotiateorReviselntragovemmentalOrder 

InitiateProcurementChangeRequest 

EstablishSourcingVehiclewithGovernment 

Sources 

1 

IdentifyandReserveSupplyChainResources 

ManagelnboundandOutboundShipments 

TransportMaterielandForces 

AssembleandMarshalForces 

CollectProgramlnformation 

ReceiveandPrioritizeRequirements 

ManageTravel 

SignAgreementwithGovernment  Requester 

CoordinatewithSupplier 

RespondtoSolicitation 

ConductMarketResearch 

CollaborativelyDeveloporModify  Agreement 
with  GovernmentSupplier 

DetermineResourcelmplications 

ProcessContractClauses 

DetermineRouteandCarriers 

StageContractorOrder 
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BEA  Processes 
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ConsolidateProgramChangeProposal 


ImplementESOHSolution 


DeveloporCollectEnvironmentalLiability 

Documentation 


CompilelssueBooks 


ExecuteApportionmentandAllocateFunds 


WithdrawFunds 


ReviewRescission  Requirements 


ExecuteRealPropertyAcceptanceTransactions 


ForecastDemand 


ExecuteContractCloseout 


CalculatePaymentAdjustments 


PrepareDoD'sInitialPresident'sBudget 

Submission 


AdministerAssignmentAction 


PerformBudgeting 


EstablishEffectiveandPostingDateofChange 


CollectBudgetlnformation 


ExecuteProgram 


UpdateChartofAccountsandSFISAttributeand 

ProFormaEntriesandCalendar 


UpdateAnomalyDetectionCriteria 


ConductResearch 


ReviewOutstandingAdministrativeBalance 


ImproveAndValidateAssumptions 


AccumulatetoModelElement 


ReviewModelResultsWithCustomer 
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BEA  Processes 


ConsolidateandlnterpretResults 


PerformPhysicalAssetAccountability 


FileRealPropertyDiscrepancyReport 


PerformRealPropertylnspectionsand 

Verifications 


CoordinatewithComponents 


VerifyCommissioningRequirements 


GenerateDeferralReport 


AcknowledgeRealPropertyServicesRendered 


ConfirmReceiptofUniformRelocationsAct 

Information 


DetermineRe-apportionment 


GenerateDraftBaselineReport 


VerifyTitleSearch 


PrepareRequirementsforSubmissionto 

Congress 


IncorporateFeedback 


ReceiveDesignApprovalResponse 


GenerateDraftProgramReport 


GenerateDraftRebaselineReport 


AnalyzeAnomalies 


EstimateTimeandCostofCorrectiveActions 


VerifyAccuracyandCompletenessof 
Environmental  Liability 


Develop  Proposed  RescissionLanguage 


CreateProgramandFundingDocument 


PerformConstructionRestoration 

Modernization 


IdentifySpread 
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BEA  Processes 

BEIS 

DAI 

EBS 

DEAMS 

ECSS 

GCSS-Army 

GFEBS 

UpdateProgramandFundsInformation 

PerformlnstallationsSupport 

AggregateRealPropertyManagement 

Information 

ConfirmProofofTraining 

ScheduleClosingorSigningwithProvider 

ValidateReportingDocumentation 

EstablishandUpdateValuationConventions 

NotifyAcceptingOfficials 

VerifyEnvironmentalLiabilitySummary 

Documentation 

CompleteReviewandApproveFinalDesign 

Solution 

ApplyPaymentlnstructions 

DetermineAvailabilityofRequiredData 

ProcessApprovedRequirement 

GenerateForecast 

ReviewModelwithCustomer 

ReCalculatePrincipalBalance 

Grand  Total 

(N 

(N 

300 

o 

165 

316 

IV 

cn 

341 

LMP 

NAVY-ERP 

GCSS-MC 
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Appendix  D.  Performance  Measures 


Performance  management  is  required  for  all  levels  of  DoD  activities.  The  perfonnance 
management  requirements  for  the  business  systems  are  intended  to  ultimately  show 
strategic  alignment  to  the  Quadrennial  Defense  Review  (QDR)  goals  and  objectives.  In 
turn,  alignment  to  operational  goals  and  objectives-external  and  internal  performance 
goals  and  objectives  on  the  program  level-can  then  be  achieved.  Each  level  must 
determine  the  most  meaningful  type  of  measures  to  accurately  track  and  report 
performance.  For  example,  at  the  strategic  level,  responsibility  for  reporting  compliance 
with  internal  controls  and  with  strategic  goals  and  objectives  requires  different  metrics 
than  at  the  operational  level,  which  requires  metrics  for  the  scope  of  the  operational  unit 
only.  Similarly,  the  program  level  requires  identification  and  tracking  of  perfonnance 
metrics  for  program/contract  milestones  and  mission  perfonnance,  including  a 
description  of  baseline,  target,  and  quantitative  measurement  indicators. 

In  the  case  of  performance  management  for  financial  management,  the  strategic  level 
requires  the  Executive  responsible  to  adhere  to  the  OMB  guidance  for  ensuring  that 
internal  controls  are  in  existence  and  are  followed  in  a  consistent  and  comprehensive 
manner.  The  OMB  guidance  checklists  and  similar  reporting  requirements  comprise  the 
metrics  that  ensure  controls  are  effective.  At  the  strategic  level,  there  are  several  reports 
that  include  financial  management  performance  goals  and  objectives  and  that  map 
performance  to  the  QDR.  For  example,  the  DoD  Performance  Report  and  DoD 
Performance  Budget  Plan,  as  well  as  the  DoD  Budget  Request  and  other  budget-related 
documents.  The  metrics  for  strategic  goals  and  objectives  need  unique  high-level 
performance  metrics  to  ensure  progress  is  being  made  at  the  strategic  level. 

At  the  operational  level,  financial  management  performance  metrics  are  more  specifically 
tied  to  the  people,  processes,  and  technology  that  would  lead  to  a  clean  audit.  The 
metrics  for  auditability  include  the  level  of  training  and  knowledge  of  the  personnel;  the 
ability  to  collect  and  post  accurate  and  complete  data  in  the  correct  accounts,  and  the 
capability  of  systems  to  automate  and  generate  accurate  reports  from  the  data.  Each 
organization  at  the  operational  level  does  not  necessarily  have  the  same  processes,  or 
therefore  the  same  performance  metrics,  but  needs  to  design  and  develop  systems  and 
metrics  to  reflect  their  mission  needs  for  financial  management.  The  organizational 
performance  metrics  may  be  derived  from  a  standard  or  custom  financial  audit  checklist 
to  cover  all  financial  areas.  For  the  Enterprise  level,  the  question  is  how  the  processes  and 
technology  of  the  individual  organizations  with  different  data,  processes,  and  technology 
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may  or  may  not  be  adequately  merged,  with  effective  metrics  to  measure  success,  in  an 
overall  financial  management  system  that  will  result  in  a  clean  audit  for  the  enterprise. 

At  the  program  or  project  level,  very  discreet  perfonnance  metrics  may  be  identified, 
tracked,  and  reported  for  financial  management  and,  specifically,  for  auditability 
purposes.  This  level  should  have  metrics  tied  to  accepted  accounting  practices  and 
standards  and  unique  valuation  methods  for  operating  units,  as  well  as  metrics  for 
personnel  training  and  expertise,  adequacy  of  processes,  and  system  perfonnance. 

The  following  describes  and  provides  the  status  of  the  major  performance  management 
mechanisms  currently  in  force  for  DoD  for  the  Enterprise,  Operational,  and  Transactional 
Views. 

D.l.  Enterprise  View 

D.1.1.  Office  of  Management  and  Budget  Internal  Controls 

OMB  A- 123  lists  nine  statutory  requirements  documents  for  internal  controls  related  to 
financial  reporting,  including  the  Chief  Financial  Officers  (CFO)  Act  and  the  Federal 
Financial  Management  Improvement  Act  of  1996  (FFMIA).  Compliance  with  the  CFO 
Act  and  the  FFMIA  is  specifically  noted  by  the  majority  of  ERP  initiatives  in  their 
submissions  to  the  OMB  Exhibit  300.  The  ERPs  also  state  compliance  with  the  Business 
Enterprise  Architecture  (BEA).  The  Federal  Managers  Financial  Integrity  Act  of  1982 
(FMFIA),  though  not  listed  by  the  initiatives  as  a  compliance  requirement,  includes  a 
requirement  for  DoD  to  provide  a  Statement  of  Assurance  that  the  agency  has  reasonable 
assurance  that  controls  are  achieving  the  intended  objectives,  and  materiel  weaknesses 
and  corrective  action  plans  are  reported.  This  Statement  of  Assurance  is  required  as  part 
of  the  annual  Perfonnance  and  Accountability  Report  (PAR)  required  by  OMB. 

D.1.2.  DoD  Performance  Reports  and  Plans 

The  Quadrennial  Defense  Review  (QDR)  sets  the  strategic  goals  and  objectives  for  the 
DoD.  The  DoD  Budget  Request  Overview;  DoD  Performance  Report,  DoD  Performance 
Budget  Plan,  DoD  Strategic  Management  Plan,  Agency  Financial  Report 
(AFR)/Performance  and  Accountability  report  (PAR),  Program  Assessment  Rating  Tool 
(PART),  and  Annual  Management  Reports  (AMR),  are  all  mechanisms  to  document  and 
track  program  performance  at  a  strategic  level.  In  addition,  the  intent  of  the  BEA  is  to 
provide  a  repository  for  common  processes,  data,  and  describe  other  common  elements, 
including  performance.  The  OMB  EA  Assessment  (that  is  now  in  hold  status)  also 
required  segment  owners  to  report  performance  from  the  strategic,  segment,  and 
investment  level  as  a  way  to  ensure  alignment  of  program  goals  with  strategic  goals.  All 
of  these  reports  are  intended  to  meet  the  requirements  for  internal  controls  as  described  in 
the  OMB  A- 123. 
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The  following  describes  the  DoD  reports  and  plans,  and  the  current  status: 

1.  FY  2011  Budget  Request  Overview  of  Feb  20101  includes  Section  7,  Performance 
Improvement.  This  section  describes  the  content  of  the  FY  2009  DoD  Performance 
Report  and  the  FY  2011  DoD  Perfonnance  Budget  Plan  that  relates  to  strategic  objectives 
and  specific  performance  targets. 

2.  FY  2009  DoD  Performance  Report2  is  included  as  part  of  the  FY  2011  Budget 
Request  Overview.  The  Report  identifies  performance  targets  aligned  with  QDR  strategic 
goals  and  objectives,  including  Strategic  Goal  4:  Integrate  Business  Operations.  Goal 
4.2U  aims  to  “strengthen  financial  management  activities.” 

3.  FY  2011  Performance  Budget  Plan3  is  included  as  part  of  the  FY  2011  Budget 
Request  Overview  and  is  required  per  statutory  provisions  of  the  Government 
Perfonnance  and  Results  Act  (GPRA)  of  1993.  The  Plan  has  revised  performance  targets 
based  on  the  President’s  High  Priority  Performance  Goals  (HPPG)  and  the  DoD  Strategic 
Management  Plan.  One  of  the  HPPGs  goals  is  to  “increase  the  audit  readiness  of 
individual  DoD  Components.”  The  following  performance  measures,  under  the 
responsibility  of  the  USD  (C/CFO),  are  included  (with  other  financial-related 
measurement  indicators)  to  meet  annual  and  long-term  performance  goals  for  financial 
management: 

•  Percentage  of  audit-ready  assets  (deleted  for  FY  2011  by  request  of  the  USD 
Comptroller) 

•  Percentage  of  audit  ready  liabilities  (deleted  for  FY  2011  by  request  of  the  USD 
Comptroller) 

•  Percentage  of  DoD  Statement  of  Budgetary  Resources  (SBR)  Appropriations 
received,  validated  (target  of  100%  reviewed,  verified,  and  approved  as  audit- 
ready  by  FY  2013.  The  target  for  FY  2011  is  80%.) 

•  Percentage  of  DoD  SBR  validated  (target  of  100%  validated  as  audit-ready  by  FY 
2017.  The  target  for  FY  2011  is  14%. ) 

In  addition,  Goal  4.2U  includes  the  following  measure  under  responsibility  of  the 
DCMO: 

•  Percentage  of  enterprise  level  business  services  deployed  within  1 8  months  of  the 
capability  business  cases  approval  (target  of  80%  deployed  within  18  months  by 
FY  2012.  The  target  for  FY  201 1  is  50%.) 


1  DoD  Fiscal  Year  2011  Budget  Request,  February  2010,  OSD/CFO. 

2  FY2009  DoD  Performance  Report. 

3  FY201 1  DoD  Performance  Budget  Plan. 
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4.  DoD  Strategic  Management  Plan  (SMP):  The  July  2009  SMP  states  that  an  annual 
review  led  by  the  DCMO/CMO  develops  a  set  of  integrated  business  priorities  that 
address  key  performance  measures.  The  main  output  of  this  review  is  the  SMP  that  also 
provides  input  to  the  Performance  Budget  and  Report  as  part  of  the  DoD  budget 
submission.  The  performance  framework  described  in  the  SMP  includes  several  steps, 
including:  plan,  set  targets,  cascade  measures,  align  processes,  assess  and  report,  and 
correct. 

This  2009  version  of  the  SMP  includes  some  top  priorities  developed  by  the  Army,  Navy, 
and  Air  Force  CMOs,  but  the  Anny  is  the  only  Component  that  specifically  notes  ERP- 
related  priorities:  re-engineering  business  processes  to  improve  performance  and 
providing  integrated  supply  chain  support.  Although  the  SMP  describes  it’s  framework  in 
a  way  that  should  result  in  effective  performance  metrics,  the  July  2009  version  does  not 
have  comprehensive  priorities  or  related  perfonnance  metrics  on  either  the  Enterprise  or 
Component  level.  The  2010  SMP  is  currently  in  development  and  should  be  released 
soon.  The  2010  SMP  is  planned  to  include  more  concrete  performance  metrics  and 
alignments  between  the  strategic  level,  the  BEA,  and  Business  Process  Re-engineering 
(BPR). 

5.  Financial  Improvement  and  Audit  Readiness  (FIAR),  May  2010:  Lists  specific 
performance  goals,  objectives  and  related  metrics.  Recently,  there  has  been  an  increased 
and  joint  emphasis  by  the  DCMO  and  the  OSD(C)  focused  on  the  SBR. 

6.  Agency  Financial  Report  (AFR)/Perfonnance  and  Accountability  report  (PAR), 
November  2009:  The  performance  metrics  in  the  AFR  are  based  on  the  QDR  2006  goals 
and  objectives.  The  QDR  2010  has  since  been  released;  therefore,  the  performance 
metrics  in  the  AFR  are  no  longer  current.  For  FY  2009,  DoD  chose  to  produce  the  DoD 
Agency  Financial  Report  (AFR)  as  an  alternative  to  the  PAR.  The  Agency  Financial 
Report  (AFR)  for  FY  2009  includes  three  components:  the  AFR,  that  provides  executive- 
level  information  on  the  Department’s  history,  mission,  organization,  key  perfonnance 
activities,  analysis  of  the  financial  statements,  controls  and  legal  compliance;  the  Annual 
Performance  Report  (APR),  that  is  included  in  the  Congressional  Budget  Justification  and 
will  provide  the  detailed  perfonnance  information  and  description  of  results  by 
performance  measures;  and  the  Summary  of  Performance  and  Financial  Information,  that 
will  summarize  the  Department’s  financial  and  performance  information.  The  AFR  was 
published  on  November  16,  2009.  The  APR  and  the  Summary  of  Performance  and 
Financial  Information  were  planned  to  be  published  in  February  2010  but  have  not  yet 
been  released  (or  at  least  not  posted  on  DCMO  website). 

The  November  2009  AFR  includes  a  Statement  of  Assurance,  signed  by  Deputy 
Secretary  of  Defense  William  J.  Lynn  states  that  the  Department  used  OMB  A- 123, 
Appendix  A,  “Management’s  Responsibility  for  Internal  Controls”  to  assess  internal 
controls  over  financial  reporting  per  the  objectives  of  the  Federal  Managers’  Financial 
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Integrity  Act  (FMFIA).  The  evaluation  determined  that  “reasonable  assurance  cannot  be 
made  that  internal  controls  over  financial  reporting  are  effective  as  of  June  30,  2009. ”4 
Also,  the  evaluation  concluded  that,  as  of  November  2009,  “the  Department’s  financial 
systems  are  not  in  substantial  compliance  with  the  Federal  Financial  Management 
Improvement  Act  (FFMIA).”  The  Statement  further  says  some  broad  initiatives  including 
program  and  senior  management  responsibility  to  internal  management  controls  and  a 
focus  on  responsible  planning  to  resolve  financial  reporting  and  materiel  weaknesses  is 
ongoing.  According  to  the  Statement,  the  FIAR  initiative  and  systems  modernization 
efforts  as  reflected  in  the  ETP  demonstrate  measured  progress.  The  DoD  FY  2009 
Perfonnance  Report  and  the  FY  2011  DoD  Performance  Budget  Plan  are  included  in  the 
FY  2011  Budget  Request  published  in  February  2010.  Note:  The  AFR  has  not  been 
updated  for  QDR  2010  and  does  not  include  the  DoD  Summary  of  Perfonnance  and 
Financial  Information  that  was  planned  for  release  in  February  2010. 

7.  Program  Assessment  Rating  Tool  (PART).  The  PART  assesses  a  limited  number  of 
initiatives;  the  ERPs  are  not  currently  being  assessed. 

8.  The  BEA  is  discussed  in  detail  in  Appendix  E. 

9.  The  OMB  IT  Dashboard  is  a  tool  for  monitoring  IT  projects.  The  OMB  IT  Dashboard 
includes  the  same  performance  metrics  and  tracking  information  that  Components  submit 
for  the  Exhibit  300s.  It  is  lacking  in  usefulness  from  the  performance  perspective  for  the 
same  reasons  as  the  Exhibit  300s,  as  discussed  below  in  the  Transactional  View  section. 

In  addition,  the  DoD  Information  Technology  (IT)  Budget  Estimates  in  the  FY  2011 
President’s  Budget  Request5  includes  the  Selected  Capital  Investments  Report  with 
information  about  each  major  ERP  initiative.  This  infonnation  primarily  includes  cost 
milestones/schedules,  and  funding  accomplishments  but  does  not  include  specific 
performance  metrics  or  measures. 

Most  of  these  strategic  level  reports  have  goals  and  objectives  that  are  at  too  high  a  level 
to  be  effective  except  to  show  broad  alignment  with  QDR  goals.  For  example,  there  are 
some  perfonnance  metrics  in  the  FY  2011  Budget  Request  Overview  of  February  2010, 
Exhibit  A,  for  Strategic  Goal  4,  “Integrate  Business  Operations,”  as  measures  for 
Enterprise-level  goals,  but  no  metrics  that  can  measure  the  effectiveness  of  the  steps  to 
accomplish  the  strategic  goal. 

There  is  also  no  consistency  between  the  strategic  goals  in  the  FY  2011  DoD 
Perfonnance  Report  and  in  the  DoD  Performance  Budget  Plan  (as  described  in  the  FY 
2011  Budget  Request  Overview,  Exhibit  A)  or  in  the  Component  goals  listed  in  the  DoD 


DoD  Agency  Financial  Report  for  Fiscal  Year  2009,  November  16,  2009. 

5  FY  2011,  President’s  Budget  Report,  DoD  Information  Technology  Budget  Estimates,  Selected  Capital 
Investments  Report,  OSD  (Nil),  DASD-R,  Resource,  Program  Budget  Office,  Mar  2010. 
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Strategic  Management  Plan.  Also,  the  FY  2009  AFR  is  outdated  and  does  not  include  the 
planned  (February  2010)  performance-related  documents  it  promises  on  the  DCMO 
website.  It  is  unknown  whether  the  Performance  Improvement  Section  7  in  the  FY  2011 
Budget  Request  Overview  is  intended  to  encompass  the  DoD  Perfonnance  Report  and  the 
DoD  Performance  Budget  Plan  or  if  there  are  separate  documents  for  those. 

D.2.  Operational  View 

The  following  description  of  the  current  status  of  the  operational  view  is  limited  to  the 
performance  metrics  noted  in  the  Enterprise  Transition  Plan  (ETP)  for  the  Business 
Enterprise  Priorities  (BEPs)  that  represent  the  functional  or  core  business  missions. 

The  FY  2010  ETP  was  released  in  December  2009  and  includes  six  BEPs.  The  BEPs  are 
Personnel  Visibility,  Acquisition  Visibility,  Common  Supplier  Engagement,  Materiel 
Visibility,  Real  Property  Accountability,  and  Financial  Visibility.  There  are  perfonnance 
metrics  for  each  area  by  BEP,  Program,  and  Initiative  via  charts  for  each  perfonnance 
metric  to  show  progress  by  year.  As  an  example,  the  Business  Enterprise  Infonnation 
Services  Family  of  Systems  (BEIS  FoS)  section  describes  the  BEIS  FoS  and  also  has  a 
chart  for  SFIS  compliance  growth  by  percentage  for  FY  2009  and  FY  2010  including  the 
baseline,  actual,  and  target  goals.  There  is  also  a  Budget  Chart  for  BEIS  FoS  by  millions 
of  dollars  for  2008,  2009,  and  2010. 

The  March  2009  Report  on  Defense  Business  Operations  to  the  Congressional  Defense 
Committees  in  the  Financial  Visibility/Financial  Reporting  section,  states  that  “progress 
in  financial  reporting  is  measured  by  the  percentage  of  Defense  assets  reported  using 
standardized  financial  reporting.  The  goal  for  this  measure  is  100%.  The  measure  is 
derived  by  taking  the  sum  of  all  the  assets  and  dividing  it  by  the  sum  of  the  assets  that  use 
the  Business  Enterprise  Information  Services  Family  of  Systems  (BEIS  FoS)  -  compliant 
budgetary  reporting  process.  The  percentage  of  accounting  assets  that  are  reporting  using 
standard  codes  provides  a  clear  indicator  of  progress  toward  Enterprise  standardization.” 

In  reviewing  Section  6,  Key  Milestone  Summary  of  the  March  2009  Report,  the  list  of 
milestones  are  all  program  milestones,  not  true  mission  perfonnance  milestones;  in  fact, 
the  perfonnance  metric  for  measuring  the  percentage  of  Defense  assets  using  SFIS  is  not 
included.  Moreover,  no  other  true  performance  metrics  or  related  baseline,  target,  and 
actual  results  exist  for  other  BES  areas.  None  of  the  milestones  in  the  Key  Milestone 
Summary  are  clearly  linked  to  the  strategic  goals  and  objectives  as  described  in  the 
individual  BEP  sections  of  the  Report. 

The  March  2010  Report  on  Defense  Business  Operations  to  the  Congressional  Defense 
Committees  in  the  Financial  Management  section  does  not  include  any  performance 
metrics  for  BEIS  (FoS)  as  in  the  2009  Report  but  does  summarize  goals  and  objectives. 
As  in  the  2009  Report,  the  Key  Milestones  Summary  only  includes  program  milestones, 
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not  mission  perfonnance  metrics  or  related  baseline,  target,  and  actual  results;  nor  does 
the  Key  Milestones  Summary  include  any  clear  linkages  to  goals  and  objectives  listed  in 
the  Financial  Management  section.  As  mentioned  above,  the  FY  2010  ETP  does  have 
charts  with  perfonnance  metrics,  baseline,  target,  and  actual  results. 

There  is  a  statement  in  the  March  2010  Report  that  “Effective  this  year,  financial 
improvement  and  audit  readiness  efforts  within  the  FIAR  Plan  emphasize  improvement 
in  processes  that  directly  relate  to  financial  information  most  useful  to  the  Department’s 
leaders  and  managers.”  Also,  “A  more  robust  internal  control  environment  has  been 
implemented  via  the  DoD-wide  Manager’s  Internal  Control  Program  (under  standards 
provided  by  OMB  Circular  A- 123).  It  supports  improved  financial  stewardship  through 
stronger  internal  controls  that  reduce  opportunities  for  waste,  fraud,  and  abuse  while 
identifying  and  maximizing  efficiencies  and  cost  savings.  Efforts  to  strengthen  internal 
controls  over  financial  reporting  continue  as  part  of  the  overall  FIAR  effort.” 

Overall,  the  segment  level  performance  metrics  for  the  BEPS,  whether  listed  in  the  ETP 
or  in  the  2009  or  2010  Report  on  Defense  Business  Operations  to  the  Congressional 
Defense  Committees,  are  limited  and  are  not  clearly  mapped  to  strategic  goals  and 
objectives.  The  perfonnance  metrics  do  not  appear  to  be  a  primary  focus  for  the  BEPs,  at 
least  not  with  the  same  focus  as  the  program  milestones.  There  are  efforts  to  improve 
financial  management  auditability  and  internal  controls  through  the  FIAR  effort,  as  noted 
in  the  FY  2010  Report  on  Defense  Business  Operations.  The  FIAR  does  include  specific 
performance  metrics  that  may  serve  as  BEP  perfonnance  metrics  for  financial 
management  as  well,  at  least  in  the  area  of  financial  management. 

D.3.  Transactional  View 

The  OMB  Exhibit  300s  includes  a  section  called,  “Performance  Infonnation”  for  the 
Components  to  note  the  specific  measurement  indicator  (or  metric)  for  each  investment 
and  the  baseline,  target,  and  the  actual  status  of  the  metric  by  Measurement  Area.  The 
Measurement  Areas  and  sub-functions  are  derived  from  the  Federal  Enterprise 
Architecture  Consolidated  Reference  Model  (FEA  CRM). 

The  perfonnance  metrics  submitted  by  Components  for  the  Exhibit  300s,  an  OMB  A-l  1 
requirement  for  major  investments,  have  been  suspect  since  inception  of  the  requirement. 
The  Components  and  program  personnel  who  submit  the  performance  metrics  for  their 
investments  may  lack  knowledge  in  regard  to  how  to  identify,  measure,  and  track 
performance  or  may  not  have  a  clear  understanding  of  how  the  metrics  are  used  by  OMB. 
Also,  when  systems  are  in  development  status,  the  metrics  selected  may  not  be  relevant 
for  when  the  system  is  actually  fielded. 

Other  issues  are  that  the  wrong  kinds  of  metrics  (such  as  contract  data  versus 
quantitative,  measurable  metrics)  are  submitted  or  metrics  are  not  consistent  from  year  to 
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year  and  therefore  are  not  valuable  to  measure  progress  or  trends.  In  addition,  in  the  case 
of  the  OMB  Exhibit  300,  a  minimum  of  only  one  metric  for  each  of  four  measurement 
areas  over  several  years  is  required.  These  measurement  areas  are  Mission/Business 
Results,  Customer  Results,  Process  &  Activities,  and  Technology,  based  on  the  Federal 
Enterprise  Architecture  Consolidated  Reference  Model  (FEA  CRM)6.  The  performance 
metrics  as  required  by  OMB  in  the  Exhibit  300s  have  not  been  well  understood  by  the 
programs,  therefore,  in  many  cases,  are  neither  appropriate,  quantitative,  or 
comprehensive,  leading  to  a  lack  of  credibility  about  their  usefulness.  Even  if  effective 
metrics  are  identified  and  tracked,  the  minimal  set  of  metrics  required  is  not  adequate  to 
measure  progress  or  improvements. 

In  summary,  performance  improvements  and  related  outcomes,  rather  than  just  outputs, 
have  been  rightly  promoted  as  a  way  to  justify  budgets  for  new  and  ongoing  programs  by 
showing  concrete  progress.  The  reality  is  that  the  measures/metrics  that  have  been 
reported  to  date  in  the  various  reporting  documents  have  generally  been  either  too  high 
level  with  not  enough  detail,  or  the  wrong  kind  of  metrics  (such  as  contract  data  versus 
quantitative,  measurable  metrics),  or  are  not  consistent  from  year  to  year  (therefore  not 
valuable  to  measure  progress);  therefore  leading  to  a  lack  of  credibility  about  their 
usefulness.  The  ability  to  measure  actual  or  projected  performance  is  limited  because  the 
performance  metrics  used  are  generally  not  comprehensive,  are  geared  to  a  specific 
functional  area,  and/or  are  at  too  high  a  level  to  be  an  effective  metric. 
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Committee  on  Armed  Services,  House  of  Representatives.  Assessment  of  Defense  Information 
Technology  Systems  for  Financial  Management,  National  Defense  Authorization  Act  for  Fiscal  Year 
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Appendix  E.  Architecture 


This  Appendix  presents  a  discussion  about  the  need  for  an  Operational  Concept  to 
describe  the  target  state  and  to  serve  as  a  foundation  for  the  architecture  going  forward.  In 
particular,  the  need  for  an  operational  concept  and  architecture  that  focus  on  the  basics: 
the  Department  of  Defense  as  a  collection  of  organizations  where  each  organizational 
unit  has  its  own  people,  with  potentially  unique  processes,  and  tools  (technology);  all  of 
which  contribute  to  a  high  degree  of  operational  efficiency  and  a  clean  audit  opinion.  It 
also  presents  findings  and  recommendations  about  the  Business  Enterprise  Architecture 
(BEA),  how  it  is  serving  the  needs  of  the  Department  in  relation  to  the  ERPs,  and 
recommendations  for  improvement. 

The  inefficiencies  associated  with  each  organization  having  its  own  processes  and  tools  is 
a  well  known  problem.  The  problem  is  rooted  in  processes  variation  and  lack  of  common 
tenninology.  It  is  therefore  critical  to  understand  and  document  the  vision  for  the  target 
state  in  an  Operational  Concept  which  acknowledges  when  and  where  processes  can  be 
made  common  and  where  unique  processes  are  indicated.  In  addition,  development  of 
architecture  that  documents  people/processes/tools  and  architecture  that  documents  more 
granular  views  of  the  enterprise  are  tools  for  helping  large  enterprises  become  high- 
performing  organizations  that  enable  the  identification  of  sharing  opportunities.  The 
resulting  understanding  of  the  variations  and  an  agreement  to  share  common  processes, 
coupled  with  a  vision  for  a  more  efficient  target  state,  are  necessary  for  transformation 
and  business  optimization. 

E.l.  Target  State 

From  an  executive  point  of  view,  the  target  state  (environment)  includes  ‘people,’ 
‘processes,’  and  ‘tools’  (an  architecture)  which  are  based  on  a  vision  formed  from  the 
current  operational  concept,  the  issues  associated  with  the  current  operational  concept, 
and  from  an  understanding  of  other  (alternative)  operational  concepts  and/or  business 
models.  The  primary  purpose  of  the  BEA  continues  to  be  the  elimination  of  financial 
management  related  material  weaknesses  and  specifically  to  provide  the  Department  with 
a  set  of  blueprints  that  facilitate  their  ability  to  acquire  a  clean  audit  opinion.  However, 
the  BEA  does  not  provide  a  vision  of  the  target  state,  nor  does  it  provide  an  operational 
concept  for  the  target  state  and  a  clear  and  concise  statement  about  how  the  BEA  will 
fulfill  its  primary  purpose. 
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Early  releases  of  the  BEA  launched  by  the  BMMP  contained  a  vision  and  concept  of 
operations  based  on  the  Porter  Value  Chain  model.  It  is  now  the  Department’s  role  and 
responsibility  (a  leadership  role  and  responsibility)  to  establish  (or  re-establish)  the  vision 
and  operational  concept  and  drive  the  PPBE  to  launch  a  set  of  investments  that  are  based 
on  an  improved  BEA  which  will  eliminate  material  weaknesses  and  lead  to  a  clean  audit 
opinion  in  a  reasonable  timeframe.  Note:  Elements  of  the  vision  and  operational  concept 
are  part  of  this  report  and  graphical  depictions  are  included  in  the  accompanying  CD. 

E.2.  Operational  Concept 

A  clear  vision  of  the  target  state  is  essential  for  an  actionable  Operational  Concept  for 
DoD  business  operations.  There  are  business/operating  models  and  terms  that  can  be 
applied  to  develop  an  Operational  Concept  and  establish  the  clarity  required  to  move 
forward.  The  model  and  terms  permit  the  right  amount  of  capability  overlap,  encourage 
the  creation  of  shared  services,  and  set  the  stage  for  ongoing  auditability. 

An  example  of  an  appropriate  business  model  is  the  Porter  Value  Chain  Model  and  the 
concept/term  is  Business  Operating  Units  (BOU)  or  simply  Operating  Unit.  An  operating 
unit  is  an  organizational  unit  within  an  enterprise  that  holds  assets,  liabilities,  and 
reporting  responsibility  for  both.  If  embraced,  the  BOU  concept  can  lead  to  an 
arrangement  of  one  ERP  system  per  operating  unit,  where  the  ERP  is  acting  as  a  system 
of  systems  backbone  with  a  SFIS  compliant  general  ledger  or  a  summary  ledger.  The 
ERP-based  backbone  would  act  as  an  integrating  platfonn  for  selective  integration  of 
other  strategic  and  mission  critical  systems. 

To  realize  this  Operational  Concept,  the  department  can  identify  the  operating  units, 
identify  the  non-operating  units  (NOU)  found  within  each  operating  unit,  and  then 
document  systems  used  by  the  operating  and  non-operating  units.  Figure  E-2  compares 
the  attributes  of  operating  and  non-operating  units.  The  model  presented  in  Figure  E-2 
can  be  used  to  document  this  infonnation. 
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‘Operating  Units’ 

Figure  E-1.  Enterprise  Organizational  Building  Blocks 
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Non-operating  units  and  the  processes  they  execute  are  potential  shared  services; 
collectively,  the  operating  and  non-operating  units  are  the  organizational  building  blocks 
of  the  enterprise.  These  units,  their  arrangement,  the  processes  they  execute,  and  the 
systems  used  must  be  part  of  the  Department’s  BEA.  The  model  depicted  in  Figure  E-2 
enables  the  BEA  to  capture  process  maturity  information.  This  is  not  a  theoretical 
maturity  rating;  rather  it  is  the  maturity  of  a  process  as  executed  by  a  particular 
organization  using  a  particular  process  and  system.  With  this  information,  the 
Department  can  compare  and  contrast  the  performance  of  one  organizational  unit  and  its 
performance  with  a  particular  process  against  that  of  another  organizational  unit. 

Leveraging  incremental  progress  and  repeating  those  accomplishments  across  the 
Department  is  essential  and  should  be  rewarded.  For  example,  the  Department  should 
rally  resources  (practitioners)  around  the  Marine  Corps  Statement  Budgetary  Resources 
(SBR)  initiative  to  assure  its  success  and  to  ensure  that  it  serves  as  a  model  (M-Field)  for 
other  Components  and  Defense  Agencies  to  do  the  same.  The  Marine  Corps  work  could 
then  serve  as  a  model  and  a  set  of  requirements  for  the  processes  and  the  systems  that 
automate  the  processes.  This  would  be  an  example  of  a  smaller  scale  initiative  being 
leveraged  to  repeat  a  similar  accomplishment  in  a  larger  component  of  the  enterprise. 

E.3.  Business  Enterprise  Architecture 

The  overarching  purpose  of  the  BEA  is  to  address  the  Department’s  inability  to  acquire 
an  unqualified  audit  opinion.  "As  long  as  the  Department  lacks  an  effective  financial 
management  system,  the  level  of  transparency  required  to  receive  a  clean  audit  opinion 
will  remain  non-existent.  By  increasing  financial  transparency  and  moving  towards  a 
clean  audit  opinion,  the  Department  will  free  additional  resources  that  might  be  invested 
into  other  priorities.”  The  BEA  should  be  a  major  facilitator  to  satisfy  this  goal  by 
providing  DoD  users,  and  specifically  ERPs,  with  the  framework  and  building  blocks 
necessary  to  describe  common  processes,  tools,  and  terminology.  The  BEA  must 
improve  the  content  and  coordination  of  its  data  in  order  to  fulfill  this  purpose  and  to 
become  a  sought  after  resource  rather  than  just  a  checkmark  in  the  programs  list  of 
compliance  requirements.  The  following  findings  and  recommendations  are  a  result  of 
the  IDA  review  of  the  BEA  in  its  current  state. 

E.4.  Near-Term  Architectural  Findings  and  Recommendations 

The  current  financial  and  business  systems  architecture  is  based  on  the  premise  that  the 
DoD  is  an  enterprise  of  enterprises;  however,  the  BEA  does  not  provide  a  holistic  view  of 
the  enterprise  nor  does  it  document  how  the  constituent  enterprises  are  to  operate 
together.  The  definition  of  the  target  state  documented  in  an  Operational  Concept  is  the 
first  step  to  provide  the  framework  from  which  the  remainder  of  the  architecture  can 
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unfold.  The  following  set  of  findings  and  recommendations  detail  specific,  concrete,  and 
actionable  findings  that  the  Department  can  begin  to  address  immediately: 

E.4.1.  Finding:  Individually  and  collectively,  the  architectures  do  not  provide  a 
holistic  view  of  the  target  state 

Numerous  parties  and  independent  reviewers  recommended  that  the  Department  take  a 
federated  approach  but  this  led  to  architecture  disconnects  and  a  fragmented  federation. 
IDA  found  that  in  this  federation  of  architectures  there  is  no  depiction  and  no  data  that 
describe  the  real  structure  of  the  enterprise  and  no  evidence  of  closed-loop  systems, 
which  are  critical  to  managing  perfonnance  and  establishing  financial  audit  ability. 

Recommendations: 

•  Establish  a  graphical  depiction  of  the  target  state  in  an  Operational  Concept  that  is 
based  on  well-defined  terms  and  a  business  model  like  the  Porter  Value  Chain 
Model  and  that  respects  the  enterprise/organizational  structure. 

•  Assure  that  the  graphical  depiction  is  accomplished  using  the  architecture  tool  and 
using  real  architecture  artifacts  (like  organization)  that  can  be  used  to  create  the 
mapping  depicted  in  Figure  E-l. 

E.4.2.  Finding:  The  BEA  does  not  support  and  compliment  the  FIAR  plan 

The  FIAR  plan  contains  a  list  of  budgetary  resources  by  reporting  entity.  This 
information  and  a  complementary  list  of  the  systems  that  hold  those  resources  should  be 
in  the  BEA. 

Recommendations: 

•  Capture  the  list  of  reporting  entities  in  the  FIAR  plan  and  insert  them  into  the 
BEA  as  organizational  units. 

•  Configure  the  architecture  so  that  budgetary  resources  can  be  recorded  for  an 
organizational  unit. 

•  Configure  the  architecture  so  that  an  organizational  unit  can  contain  a  list  of 
systems  used  by  that  organizational  unit. 

•  Configure  the  settings  notebook  of  a  system  so  that  the  budgetary  resources  held 
by  that  system  can  be  recorded  in  the  settings  notebook  of  the  system. 

•  Establish  an  agreement  with  the  owners  of  the  FIAR  plan  to  use  the  BEA  as  the 
authoritative  source  of  this  information. 

•  The  BEA  should  document  what  information  has  to  flow  between  organizations 
and  what  SBR  scenarios  should  be  developed  to  show  how  the  scenarios  manifest 
themselves  in  the  straw  man  processes. 
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E.4.3.  Finding:  BEA  does  not  provide  guidance  on  the  application  of  ERP  systems 
like  SAP  and  Oracle 

Processes  and  Activities  provided  by  SAP  are  documented  in  SAP  Solution  Maps. 
Organizations/programs  within  the  DoD  may  not  be  familiar  with  the  SAP  Solution 
Composer  and  rely  on  systems  integrators  (SI)  to  provide  this  material.  The  BEA  can  be 
the  source  and  a  means  of  communications  on  the  activities  and  processes  that  are 
available  in  SAP  and  Oracle  and  can  provide  an  understanding  of  the  coverage  and 
relationship  between  the  activities  and  processes  provided  by  the  ERP  and  their 
counterparts  in  the  BEA. 

Recommendation: 

•  Put  information  like  the  SAP  and  Oracle  processes  and  activities,  their  names,  and 
descriptions  into  the  BEA.  Map  to  the  BEA  processes  and  activities.  This  should 
expedite  the  learning  process  and  reduce  costs. 

E.4.4  Finding:  The  ERP  Architectures  have  varying  degrees  of  maturity  and  are 
not  useful  in  managing  the  acquisition  and  qualification  of  COTS 

The  DoD  needs  to  do  a  better  job  at  following  the  DoD  Architecture  Framework 
(DoDAF)  and  using  a  Common  Architecture  Capability  (CAC)  that  includes  a  common 
architecture  toolset  used  by  all  Components  and  all  Programs. 

Recommendation : 

•  Create  and  use  style  guides  for  the  development  of  BPMN  based  process  models. 
The  style  guide  would  probably  include  specifications  such  as: 

o  All  processes  must  have  ‘entry  points’  or  ‘triggers’  in  the  form  of  BPMN 
Events 

o  All  processes  must  have  ‘outcomes’  also  in  the  form  of  BPMN  Events 
o  All  data  objects  must  be  attached  to  associated  business  events 
when/where  appropriate 

E.4.5  Finding:  The  BEA  does  not  contain  solution  level  details 

The  BEA  documents  capabilities  but  does  not  contain  a  set  of  blueprints  and  architecture 
detail  for  each  capability.  For  each  capability,  there  should  be  capability  architecture 
details  including  variance  issued  and  the  justification  for  the  variance.  Leveraging  best 
artifacts  is  preferred  over  creating  new. 

Recommendations: 

•  Establish  primitives,  patterns,  and  style  guides  as  recommended  by  the  DoD  and 
issue  BEA  compliance  to  those  programs  that  have  used  the  agreed-to  primitives 
and  patterns  and  have  followed  the  style  guide.  The  American  Institute  of 
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Architects  promulgates  standards  for  building  architecture,  and  architects  follow 
those  standards  because  first  responders  need  blueprints  that  they  can  recognize 
and  use  in  the  field  when  lives  are  at  stake.  Similarly,  an  SI  needs  blueprints  that 
show  how  processes  are  translated  into  workflows  that  are  automated/executed  by 
a  BPML-compliant  workflow  engine. 

•  Require  that  all  programs  provide  the  DCMO  with  architecture  in  System 
Architect  XML  format  and  import  the  architecture  into  the  BEA  or  into  the 
companion  System  Architect  Encyclopedias 

•  Establish  a  DoD-wide  architecture  capability  and  tool  environment  that  all 
Components  and  Defense  Agencies  can  use.  Enforce  the  standards  and  capture  the 
blueprints/documentation/artifacts  that  were  reviewed. 

•  If  variances  are  issued  to  a  program,  clearly  show  in  the  architecture  the  preferred 
process  and  the  variant.  That  is,  require  ‘as-builts’  terminology. 

E.4.6.  Finding:  BEA  lacks  key  information 

There  is  more  organizational  information  about  the  Department  in  Wikipedia  than  one 
can  find  in  the  BEA.  There  are  ‘capabilities’  that  Components  include  in  the  DITPR 
reports  for  the  ERPs  that  are  not  captured  in  the  BEA.  For  example,  the  ERP  capability 
overlap  was  analyzed  from  DITPR  reports,  not  the  BEA.  Also,  the  data  is  generally 
inconsistent  between  several  reporting  sources:  the  BTA.mil/BEA  website  and  the 
DITPR.  Further,  the  data  had  to  be  copied  from  pdf  files  and  worked  into  spreadsheets. 

Recommendations: 

•  Populate  the  BEA  with  people,  processes,  and  tools  information  and  DOTMLPF. 
Start  with  enterprise,  communities,  organizational  units  (operating  and  non¬ 
operating)  that  comprise  the  enterprise  and  communities,  and  all  the  business 
systems  (not  just  enterprise  systems). 

•  Establish  an  interface  between  BEA  and  the  DITPR  so  that  the  BEA  can 
subscribe  to  information  it  needs. 

•  Include  the  OV-4  to  represent  the  organizational  units  (people)  that  comprise  the 
Department:  OSD,  Components  (MILDEPS),  Defense  Agencies  (each  with  a 
distinct  mission),  COMMANDS,  COCOMS,  and  FORCES.  These  are  the 
organizational  building  blocks  of  the  Department. 

•  The  BEA  does  not  fully  inform  the  Department  whether  the  processes  are  fully 
automated  and  where  the  gaps  in  automation  are  because  only  a  partial  list  of 
systems  is  created. 

E4.7.  Finding:  The  BEA  is  not  the  source  of  process  details  and  requirements 

The  BEA  OV-5  is  the  authoritative  source  of  well-defined  activities  and  processes,  but 
should  leverage  and  “pull  through”  leading  practices  or  best  examples  from  MILDEPs. 
For  example,  the  Army  recorded  approximately  105  additional  financial  management 
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related  processes  that  cannot  be  found  in  the  BEA.  The  processes  appear  to  be  valid  and 
appear  to  be  applicable  to  other  Components.  If  this  is  true  then  these  processes  should 
become  part  of  the  BEA. 

Recommendations: 

•  Provide  process  detail-like  business  events  within  the  department  that  trigger  or 
are  the  outcome  of  a  particular  process. 

•  Document  the  data  that  accompanies  a  trigger  or  outcome. 

•  Document  the  data  as  the  business  people  know  it;  not  in  relational  form,  but  in 
human/book  form. 

•  Document  model  routes  through  the  process  from  trigger  to  outcome;  do  this  for 
SAP  and  Oracle  processes  out-of-the-box  and  show  how/where/why  they  vary 
from  the  COTS  process. 

•  Provide  these  variations  in  the  form  of  requirements  back  to  SAP  and  Oracle  for 
inclusion  in  future  releases. 

•  Identify  processes  that  are  fully  automated  and  where  the  gaps  in  automation  are 
by  creating  comprehensive  list  of  systems  with  the  processes  they  deliver. 

•  Collaborate  with  Components  to  ensure  processes  applicable  in  the  enterprise 
environment  are  included  in  the  BEA. 

•  Provide  straw  man  process  models  to  communicate  and  educate  both  within  the 
Components  and  within  the  SI  community.  Straw  man  processes  (developed  using 
the  preferred  style  guide)  would  cut  ERP  program  costs  in  three  respects:  money 
spent  on  as-is  and  documenting  how  processes  are  performed  by  the  Commands 
and  money  spent  educating  the  Sis. 


E.4.8.  Finding:  The  BEA  does  not  identify  the  people  (organizations)  that  execute 
processes  and  does  not  contain  a  mapping  of  the  systems  to  the  processes  and 
organizations 

The  BEA  identifies  15  end-to-end  business  flows  and  490  processes  that  are  critical  to 
business  operations  but  does  not  map  people,  processes  and  systems.  Creating  a  set  of 
end-to-end  processes  that  are,  in  theory,  organizationally  agnostic  is  analogous  to 
ignoring  the  fundamental  difference  between  a  COMMAND  and  COMPONENT. 
Implicit  in  this  approach  is  the  assertions  that  all  commands,  components  and  defense 
agencies  operate  exactly  the  same  way. 

Recommendations: 

•  Map  the  organizations,  processes,  and  systems  to  address  the  differences  and 
similarities  in  their  operating  models.  A  model  for  such  a  mapping  is  presented  in 
Figure  E-8,  A  Model  for  Correlating  Organizations,  Processes,  and  Systems. 
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•  Note  that  processes  may  and  normally  should  vary  for  organizations  except  at  the 
higher  level.  The  higher-level  processes  described  in  the  BEA  may  pertain  to  all 
organizations  but  the  organizations  may  perform  different  types  of 
processes/functions  within  the  set  of  related  processes  and  with  different  types  of 
personnel.  All  Components,  Commands,  COCOMS,  and  Deployed  Forces  do  not 
and  cannot  operate  the  same  way  based  on  their  organizational  and  mission 
requirements. 


Figure  E-2.  A  Model  for  Correlating  Organizations,  Processes,  and  Systems 
E.4.9.  Finding:  The  BEA  is  not  the  source  of  terms 

The  Department’s  Chief  Architect  envisions  the  BEA  as  a  source  of  terms  and  the 
processes  as  a  context  for  terms  but  there  are  no  apparent  plans  to  enable  the  creation  of 
terms  in  the  architecture. 

Recommendations: 

•  Modify  System  Architecture  to  support  the  creation  of  terms  and  enable  the 
creation  of  an  AV-2  diagram  where  the  terms  can  be  presented  like  a  glossary  to 
prospective  implementers  of  a  process. 

•  Enable  System  Architect  to  generate  the  AV-2  spreadsheet  as  proposed  by  the 
Chief  Architect.”7 

E.4.10.  Finding:  The  BEA  does  not  provide  a  concrete  and  intuitive 

taxonomy/model 

The  BEA  assumes  that  DoDAF  is  comprehensive  but  it  does  not  include  an  adequate 
model  for  business  operations. 


Wisnosky,  Dennis.  Architecture  in  Support  of  Business  Operations,  June  3,  2009. 
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Recommendation : 

•  Create  a  model  and  taxonomy  (triple  stores)  that  support  the  needs  of  the 
Department  and  work  to  model  business  operations. 

o  Enterprise  comprised  of  other  Enterprises  or 

o  Operating  Units  supported  by  Non-operating  unit  either  of  which 
have/provision 

o  Capability  comprised  of 

o  Services  delivered  through  the  execution  of 

o  Processes  which  may  have  Phases  and  are  comprised  of 

o  Activities  broken  down  into 

o  Task  guided  by 

o  Method  having 

o  Steps 

E.4.11.  Finding:  DoD  processes  do  not  conform  to  the  architecture  steps 

Ensure  the  Business  Capability  Lifecycle  Process  (BCLP)  supports  the  architecture 
methodology  and  ensure  that  the  aforementioned  standards  and  style  guides  are  applied  in 
recording  the  BCLP. 

•  The  process/sequence  IS: 

o  Define  requirements  (JCIDS) 
o  Architect  (DoDAF) 
o  Requisition  (iteratively  per  the  EPIC) 
o  Contract 

o  Engineer  (DOTMLPF) 
o  Build 
o  Inspect/Test 

•  The  process/sequence  IS  NOT: 

o  Requisition 
o  Contract 
o  Architecture 
o  Build 

Recommendations: 

•  Define  and  record  the  BCLP  using  the  Business  Process  Modeling  Notation 
(BPMN)  and  the  aforementioned  style  guide. 
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•  Put  the  process  into  the  BEA  (it  is  part  of  the  business  enterprise  architecture). 


E.4.12.  Finding:  DoD  architects  are  not  considered  critical  personnel 

Architects  should  be  contracted  independently  of  the  SI  with  standard/pro  forma  contract 
terms  and  conditions  that  define  the  architects’  responsibility  to  provide  certain 
architecture  detail  using  certain  standards. 

Recommendation: 

•  Hire  specialists  at  both  the  DCMO/BEA  and  program  levels  to  implement  the 
recommended  BEA  structure  and  to  work  with  one  or  two  model  programs  to  get 
the  pattern  right. 

E.4.13.  Finding:  The  Business  Capability  Lifecycle  Process  does  not  appear  to 
result  in  the  creation  of  architecture 

Unlike  the  JCIDS  and  acquisition  program  management  processes,  the  BCLP  does  not 
generate  architecture.  The  BCLP  is  new,  but  the  Department  can  leverage  existing 
processes,  such  as  the  Evolutionary  Process  for  the  Integration  of  COTS  developed  by  the 
AF  in  2002  in  collaboration  with  MITRE  and  the  Carnegie  Mellon  SEI. 

Recommendation: 

•  Embrace  the  Evolutionary  Process  for  the  Integration  of  COTS  (EPIC), 
which  understands  the  need  for  testing  early  and  often  and  the  concept  of 
converging  on  a  solution. 

E.5.  Longer-Term  Architectural  Findings  and  Recommendations 

E.5.1.  Finding:  The  current  architecture  documents  a  portion  of  the  enterprise, 
but  it  falls  short  in  the  exclusion  of  the  Combatant  Commands  and  deployed  forces. 

Recommendation: 

•  The  target  vision  and  architecture  must  be  holistic  in  its  coverage  of  the 
organization,  the  DOTMLPF  across  the  enterprise,  and  the  recording  of  both  in 
the  BEA. 

E.5.2.  Finding:  The  current  and  target  architectures  are  lacking  closed  loops  in 
the  processes  and  systems  and  the  recording  of  both  in  the  BEA. 

Closed-loop  systems  (and  processes)  are  systems  that  allow  for  feedback  and  adjustment, 
such  as  the  basic  process  of  planning,  budgeting,  and  monitoring  actual  expenditures 
against  a  budget.  The  BEA  does  not  house  performance  measurement  targets  and  do  not 
show,  through  BPMN  events,  how  the  process  responds  to  measures  taken  (actual 
measures).  For  instance,  if  performance  measures  were  taken  from  the  Exhibit  300 
documents  and  put  into  the  architecture  in  the  context  of  the  process  they  are  associated 
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with,  then  the  process  can  generate  business  events  indicating  that  thresholds  are  being 
met  or  human  intervention  is  required. 

Recommendation: 

•  Use  scenario-driven  development,  in  the  configuration  and  deployment  of 
COTS/ERP  systems.  Scenario-driven  development  is  the  mechanism  that  makes 
the  EPIC  real  and  executable.  Business  scenarios  must  be  defined  in  terms  of  the 
business  events  that  trigger  them  and  the  events  that  are  outcomes. 

E.5.3.  Finding:  Architecture  information  is  inaccessible  or  not  understandable  to 
leadership  and  management-level  decision-making  personnel 
Recommendations: 

•  Use  Google  search  and  other  Web  technologies  to  make  architecture  more  visible, 
accessible,  understandable,  and  consumable.  Google  search  tools  enable  the 
viewing  and  usage  of  the  information/content  developed  by  architects  without 
having  to  know  how  to  use  architecture  tools.  There  are  also  web-based 
technologies  that  preclude  the  need  for  the  architect  to  develop  graphical 
depictions. 

•  Expand  on  and  promote  the  DoD  Architecture  Registry  System  to  encourage 
architecture  visibility,  accessibility,  and  understandability. 

E.5.4.  Finding:  DoD  does  not  sufficiently  leverage  lessons  learned  and  commercial 
methodologies  to  improve  architecture  systems  and  processes. 

Recommendation: 

•  Leverage  methodologies  such  as  the  Evolutionary  Process  for  the  Integration  of 
COTS  (EPIC).  The  Department  needs  to  mobilize  the  right  practitioners  around 
one  entity  like  the  Marine  Corps  and  determine  what  the  processes  (architecture) 
and  systems  need  to  be. 

E.6.  Summary 

The  BEA  has  accomplished  a  great  deal  in  the  last  several  years  to  contribute  to  DoD 
efficiencies  and  overall  business  transformation.  Now,  there  are  many  areas  in  which  the 
BEA,  and  specifically  the  use  of  architecture  for  the  ERPs,  could  improve  the  way 
business  architectures  are  developed  and  implemented  even  more.  First  and  foremost  is 
the  need  for  a  vision  that  will  guide  the  Operational  Concept  for  how  the  BEA  should  be 
structured  in  a  way  that  will  provide  the  building  blocks  for  the  ERPs  and  other  enterprise 
systems.  Also,  a  better  understanding  of  organizational  structure  would  facilitate  the 
alignment  of  organizations  to  processes  and  systems  that  would  then  guide  the  developers 
to  select  processes  and  systems  that  are  the  best  fit.  The  use  of  straw  man  process  models 
would  also  show  how  the  ERPs  would  work  out  of  the  box. 
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Other  key  goals  that  DoD  should  embrace  to  improve  the  BEA  include  to: 

•  Develop  and  use  common  taxonomies 

•  Ensure  completeness  and  consistency  of  the  data  across  diverse  resources 

•  Identify  and  share  common  processes 

•  Make  architecture  artifacts  visible,  accessible,  and  useable 

Lastly,  the  BEA  and  ERPs  would  benefit  from  leveraging  the  lessons  learned  from  the 
last  several  years  of  ERP  development  in  regard  to  the  government-system  integrator 
relationship  and  leveraging  the  commercial  resources  available  for  integrating  systems 
more  efficiently. 
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Appendix  F.  Acquisition  and  Contracting 


The  choice  of  which  contract  type  is  appropriate  for  implementing  an  ERP  is  not  simple 
and  each  choice  comes  with  risks  which  must  be  recognized  and  mitigated.  There  is  no 
single  answer  to  the  question  of  which  is  applicable  in  all  cases. 

At  one  point  the  use  of  Firm  Fixed  Price  contracts  via  the  Enterprise  Software  Initiative 
(ESI)  blanket  purchase  agreement  (BPA)  was  mandated  for  ERP  implementations.  The 
mandate  to  utilize  the  ESI  vehicles  is  embedded  in  DFARS  SUBPART  208.7402.  The 
effect  of  this  was  to  force  the  ERP  programs  to  consider  the  use  of  the  ESI  pre-competed 
vehicles  unless  they  could  prove  best  value  would  be  achieved  by  the  use  of  some  other 
type  of  contract.  This  was  implemented  under  PGI  208.7403  (Acquisition  procedures). 
The  theory  was  that  this  would  give  the  Government  greater  buying  power  and  leverage 
over  price.  The  vehicles  in  place  favored  FFP  since  they  were  based  on  the  GSA  IT-70 
commercial  items  schedule,  which  only  provide  for  FFP  variants  or  pure  commercial 
T&M.  While  the  DFARS  subpart  is  still  in  place,  the  BPA  that  had  been  used  to  acquire 
integration  services  has  now  expired,  making  the  issue  moot  for  future  programs  unless 
ESI  puts  a  new  vehicle  in  place. 

Currently,  the  types  of  contract  under  which  the  ERP  programs  are  being  acquired  varies 
widely,  but  in  all  cases,  the  risks  each  type  presents  are  not  being  effectively  mitigated 
contributing  to  the  cost,  schedule  and  perfonnance  problems  of  the  ERP  programs. 

F.l.  Firm  Fixed  Price 

The  use  of  firm-fixed-price  (FFP)  contracts  is  only  appropriate  when  requirements  are 
stable,  clearly  documented  and  the  associated  risk  is  well  understood  and  mitigated. 
These  criteria  are  generally  NOT  true  in  the  initial  phases  of  an  ERP  implementation.  For 
these  reasons,  vendors  inflated  prices  to  cover  estimates  of  risk.  When  out  of  scope, 
changes  in  requirements  must  be  accommodated  the  result  is  increased  costs  and  missed 
schedule  for  the  Government. 

FFP  encourages  the  vendors  to  minimize  costs  so  they  use  lower-compensated  staff  who 
meet  the  minimum  requirements  to  do  the  work.  The  vendor  is  at  risk  if  the  Government 
was  able  to  deliver  on  its  obligations  under  the  FFP  contracts  and  leave  requirements 
untouched.  Typically,  this  is  not  the  case  and  vendors  are  able  to  offset  part  or  all  of  their 
lack  of  performance  through  Engineering  Change  Proposals  (ECPs).  In  addition,  the  way 
in  which  FFP  is  used  limits  the  Government’s  recourse,  since  rather  than  basing 
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acceptance  and  payment  on  achievement  of  operational  capabilities  or  running  software, 
they  are  often  tied  to  the  delivery  of  artifacts  such  as  design  documents.  The  quality  is 
often  difficult  to  measure  in  a  meaningful  way.  This  is  the  equivalent  of  accepting  an 
aircraft  by  taking  delivery  and  assessing  the  quality  of  each  part  and  never  looking  at  the 
airworthiness  of  the  final  assembled  aircraft  or  by  acceptance  based  upon  the  manuals 
and  designs. 

Under  FFP,  the  Government  loses  visibility  into  the  data  that  underlies  the  perfonnance 
of  the  contract.  Since  the  vendor,  in  theory,  takes  on  the  risk  of  delivering  successfully, 
they  typically  are  not  required  to  give  the  Government  transparent  visibility  into  the 
resources  they  apply  or  their  activities  as  they  execute  their  tasks.  Consequentially,  the 
Government  is  unable  to  identify  problems  prior  to  fonnal  presentation  and  acceptance  of 
deliverables. 

F.2.  Cost-Plus  Type  and  Commercial  Time  and  Materials 

The  use  of  cost-plus  or  commercial  style  time  and  materials  contracts  provides  incentives 
to  the  vendor  to  maximize  their  overall  profit  by  increasing  the  level  of  effort  associated 
with  the  execution  of  the  contract.  This  places  the  onus  on  the  Government  to  ensure  that 
they  manage  the  contract  effectively.  In  particular,  unless  specific  incentives  are  created, 
it  is  not  in  the  best,  short  term,  financial  interest  of  the  vendor  to  point  out  better  or 
optimal  ways  of  executing.  As  a  result,  these  contracts  leave  the  Government  in  the 
position  of  being  the  defacto  system  integrator,  irrespective  of  the  terms  of  the  contract. 
When  using  contracts  of  this  type  there  is  a  requirement  for  the  Government  to  staff  a 
team  of  ERP  experts  that  can  manage,  monitor  and  direct  the  activities  of  the  system 
integration  vendor. 

Another  negative  aspect  of  the  use  of  cost-plus  contracts  is  that,  as  a  rule,  the 
organizations  that  typically  bid  cost-plus  type  work  tend  to  hire  large  pools  of  relatively 
inexpensive  staff  since  this  makes  their  bids  competitive.  While  this  may  be  an 
acceptable  situation  where  the  skills  being  acquired  are  “commodity”  skills,  it  presents 
real  challenges  to  ERP  implementations.  There  is  a  limited  and  highly  paid  pool  of 
highly-skilled  individuals  who  are  desirable  to  staff  the  ERP  programs  and  they  are  not 
attracted  to  work  for  organizations  who  are  highly  incented  to  pay  the  lowest  market 
price  for  a  given  skill  level. 

F.3.  Use  of  Award  and  Incentive  Fees 

Some  of  the  deficiencies  of  cost-plus  and  fixed  price  contracts  can  be  avoided  through  the 
use  of  award  or  incentive  fees.  The  challenge  for  the  Department  has  been  in  designing 
metrics  that  are  both  meaningful  in  terms  of  describing  real  progress  towards  fielding  the 
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required  capability,  not  just  delivering  a  configured  ERP,  and  that  can  be  objectively 
assessed.  Award  or  incentive  fees  that  are  effectively  at  the  program  manager’s 
discretion,  or  where  the  achievement  of  the  required  metrics  is  outside  of  the  control  of 
the  vendor,  have  proven  worthless.  Choosing  the  wrong  or  irrelevant  metrics  on  which  to 
base  fees  drives  counter-productive  behavior  from  vendors. 

F.4.  Hybrid  Contracting  Approaches 

A  better  approach  to  contracting  would  be  to  use  a  cost-plus  type  vehicle  with  the 
appropriate  incentive  fees  for  those  aspects  of  programs  that  are  poorly  defined,  or  for  the 
early  phases  of  the  program,  and  then  to  issue  fixed-price  tasks  as  work  becomes  better 
defined.  Another  variation  of  this  approach  would  be  the  use  of  multiple  award,  multiple 
vendor  vehicles  where  each  fixed-price  task  order  can  be  competed  to  a  small  pool  of 
vendors  in  order  to  ensure  price  competitiveness  and  competitive  level  of  effort 
estimates.  This  approach  places  significant  demands  on  the  Government,  which  must 
play  the  role  of  system  integrator,  and  requires  dedicated  contracting  resources  in  order  to 
achieve  the  required  quick  turn-around  on  evaluating  proposals  and  awarding  task  orders. 

F.5.  Impact  of  Acquisition  Policy  and  Oversight 

The  interviewees  in  this  and  prior  studies  have  described  the  acquisition  system  and 
oversight  of  its  application  as  of  little  or  no  value,  and  potentially  a  detriment,  to  fielding 
a  solution.  Words  used,  for  example,  to  describe  the  system  include  “onerous,” 
“excessively  burdensome,”  and  “of  no  value.”  Despite  the  high  levels  of  oversight 

accorded  the  Major  Automated  Infonnation  Systems  (MAIS)  business  systems,  they  have 
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all  been  significantly  challenged  programs. 

The  acquisition  system  and  associated  oversight  has  not  evolved  to  support  the  rapid  pace 
of  changes  in  the  business  system  environment  necessitated  by  the  software  refresh 
cycles  of  Commercial-off-the-Shelf  (COTS)  technology  such  as  Enterprise  Resource 
Planning  (ERP)  and  the  consequent  swiftness  with  which  business  capabilities  are 
required  to  come  on-line. 

F.6.  Policy  Considerations 

Historically,  policies  for  weapons  programs  (DoD  5000  series)  and  Automated 
Information  Systems  (AIS)  (8000  series)  were  separate  as  it  was  likely  understood  that 
these  “commodities”  were  different  and  therefore  required  a  different  type  of  oversight. 


Major  Automated  Information  Systems  (MAIS),  defined  as  a  ‘special  interest’  programs;  or  programs 
with  an  estimated  cost,  in  any  single  year,  in  excess  of  $32M  or  total  program  costs  in  excess  of  $126M. 
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In  1996  the  decision  was  made  to  integrate  these  two  policies  thereby  incorporating  AIS 
policy  within  the  DoD  5000  series  of  weapon  system  policies.  Under  the  current  DoD 
5000,  MAIS  systems  are  acquired  using  the  same  life-cycle  development  process 
followed  by  major  weapon  system  acquisitions.  In  the  DoD  the  definition  of  requirements 
is  managed  under  a  separate  body  of  policy  managed  by  the  Joint  staff  under  the  CJCSI 
3170  policy  series. 

The  DoD  5000  series  is  intended  to  provide,  at  the  highest  level,  the  “framework”  in 
which  acquisition  oversight  occurs.  The  policy  states  that  programs  are  allowed  to  tailor 
and  flex  the  process  requirements  in  response  to  the  specific  needs  of  any  program. 
While  in  theory  this  is  true,  in  practice  the  DoDI  5000.02  and  associated  “Guidebook”  are 
executed  as  a  rigid  and  prescriptive  oversight  methodology.  This  lack  of  flexibility  forces 
program  offices  to  build  acquisition  programs  and  associated  implementation  strategies 
and  approaches,  in  a  very  linear  “waterfall”  manner.  The  DoD  5000  oversight 
framework  is  based  on  the  presumption  of  a  “waterfall”  development  model  which 
promotes  disciplined,  linear  progress  through  discrete,  easily  understandable  and 
explainable  phases  that  can  be  well  defined  and  documented;  it  also  provides  easily 
identified  milestone  points  along  the  way.  Milestone  and  other  decision  points  can  easily 
be  placed  at  the  beginning/end  of  any  given  phase  with  clear  criteria  for  allowing 
entrance  to  or  exit  from  a  phase. 

A  linear  approach  may  be  appropriate  for  hardware-oriented  development,  small  software 
implementations  and  complex  weapons  systems.  Its  adoption  for  COTS  based  software 
application  implementations  such  as  ERP  is  not  appropriate. 

The  “waterfall”  model  is  only  suited  to  software  projects  that  exhibit  stable,  unchanging 
and  well  defined  requirements,  and  where  it  is  likely  that  the  implementers  will  be  able  to 
fully  predict  problem  areas  of  the  system  and  produce  a  complete  design  in  early  program 
phases  that  will  require  little  or  no  subsequent  modification.  The  ERP  programs  within 
the  Department  have  proven  to  be  unstable  with  changing  requirements,  and  given  the 
complexities  described  in  this  analysis  are  highly  unpredictable,  especially  in  the  areas  of 
interfaces,  data  and  requirements.  Yet  all  of  the  ERP  programs’  execution  models  are 
aligned  around  the  DoD  5000’s  linear  waterfall  model. 

The  DoD  5000  assumes  that  requirements  in  areas  such  as  interfaces,  data,  technical 
performance,  training  and  deployment,  can  be  described  at  a  level  detailed  sufficient 
enough  to  allow  cost,  schedule  and  performance  to  be  predicted  with  some  certainty. 
These  assumptions  cannot  possibly  be  true  for  the  way  the  Services  are  attempting  to  use 
ERP  at  the  Service  enterprise  level.  The  result  of  programs  operating  under  this 
assumption  is  that  fatally  flawed  estimates  are  agreed  to  within  the  Services  and  OSD.  In 
reality,  for  ERP  programs  on  the  scale  the  Services  are  attempting,  detailed  requirements 
cannot  be  predicted,  nor  can  the  impact  of  required  cross-organizational  integration,  lack 
of  governance,  requirements  changes  and  the  unknowns  around  data  and  interface 
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complexity.  However,  the  programs  proceed  with  a  perceived  level  of  certainty  that  does 
not  exist  and,  consequently,  as  the  Government  and  the  implementers  quickly  discover  all 
of  the  true  uncertainty,  costs  go  up,  schedules  slip  or  performance  is  compromised  to  try 
to  stay  within  cost  and  schedule  estimates. 

The  policy  driven  rigidity  of  the  separation  of  the  functional  requirements  definition 
community  from  the  acquisition  community  further  exacerbates  this  problem. 

The  BTA  developed  the  Business  Capability  Lifecycle  (BCL)  as  an  alternative  oversight 
framework  for  the  MAIS  business  systems.  BCL  unifies  the  requirements  development, 
acquisition  and  investment  review  oversight  processes  under  a  single  policy.  One  of  the 
initial  goals  of  the  BCL  design  was  to  significantly  reduce  the  amount  and  redundancy  of 
documentation  required  from  the  programs  to  support  OSD  oversight.  It  is  unclear  at  the 
time  of  writing  that  the  final  version  of  the  policy  achieved  this  goal  of  reduced 
documentation  requirements.  Another  objective  of  BCL  is  to  force  much  smaller  program 
increments  which  begin  the  delivery  of  capabilities  to  users  much  sooner  than  under  the 
DoD  5000.  The  final  version  of  the  policy  was  signed  into  policy  in  November  2010  via  a 
directive  type  memorandum  from  the  USD(AT&L).  None  of  the  ERP  programs  are  yet 
operating  under  the  BCL  policy.  Pilot  BCL  pilot  programs,  such  as  ECSS,  ended  up  with 
an  increased  documentation  burden  as  they  met  both  BCL  and  DoD  5000  requirements  in 
order  to  address  the  concerns  of  the  oversight  communities  both  within  OSD  and  their 
own  Services. 

F.7.  Oversight  Considerations 

Oversight  by  OSD,  and  in  some  cases  at  the  Service  level,  has  been  consistently 
characterized  as  burdensome  and  non-value  added,  and  sometimes  characterized  as 
“oversight  by  PowerPoint.”  Further,  the  IDA  team  was  told  repeatedly  that  oversight  has 
become  more  about  personality  than  fact.  Opinions,  background,  risk  tolerance  and  the 
experience  of  individual  action  officers  and  their  principals  have  a  significant  impact  on 
the  details  of  the  execution  of  the  oversight  process.  For  example,  despite  the  specific 
tailoring  guidance  provided  in  policy,  little  or  no  tailoring  has  been  allowed  by  the 
oversight  community  since  there  is  a  perceived  personal  risk  for  them  in  allowing  it.  A 
tremendous  amount  of  documentation  is  created  in  support  of  any  given  milestone 
decision  and  numerous  meetings  of  working  integrated  product  teams  (WIPTs)  are  held. 
The  focus  of  these  WIPTs  is  less  about  what  the  program  is  actually  doing  and  more 
about  what  the  oversight  stakeholders  want  to  see  written  in  the  documentation  and  to 
make  sure  the  format  is  appropriate.  This  documentation  is  created  to  satisfy  oversight 
compliance  “check-lists”  and  is  not  used,  by  the  program  office,  to  support  the  actual 
execution  of  the  program.  Oversight  focuses  on  the  “what”  the  program  says  it  intends  to 
do  or  what  it  claims  to  be  doing,  but  does  little  to  validate  actual  execution  of  what  the 
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program  claims.  A  high  performing  organization  should  not  be  focused  on  just 
compliance. 

Oversight  is  fragmented  with  each  OSD  stakeholder  having  their  own  perspectives  on  the 
programs  shaped  by  their  own  statutory  responsibilities,  with  little  consideration  given  to 
second  and  third  order  effects  of  their  guidance.  Attempts  to  unify  the  oversight  and 
provide  a  single  definitive  voice  from  OSD  to  the  program  have  usually  just  added 
additional  layers  of  bureaucracy  since  they  have  required  consensus,  with  each 
stakeholder  having  an  effective  veto.  The  effective  veto  power  of  the  stakeholders  has  led 
to  unnecessary  slowdown  in  program  execution,  at  great  expense  to  the  programs,  while 
the  concerns  of  specific  stakeholders  are  addressed. 

In  2006,  USD(AT&L)  via  the  Business  Transfonnation  Agency  (BTA)  established  the 
Enterprise  Risk  Assessment  Methodology  (ERAM).  ERAM  was  established  due  to  a 
recognition  by  the  then  USD  (AT&L)  and  the  DUSD  (BT)  that  there  was  little  data 
reaching  OSD  about  actual  program  execution.  The  ERAM  process  has  now  been 
institutionalized  in  policy  for  MAIS  business  systems  but  the  Department  is  largely 
unprepared  to  react  to  ERAM  findings  and  unwilling  to  either  make  the  difficult  and 
unpopular  decisions  that  will  inevitably  have  to  be  made  by  both  the  acquisition  and 
functional  communities  or  to  publicly  accept  the  risks  identified.  The  oversight 
community  has  not  been  willing  to  cancel  programs  nor  make  large  changes  in  direction. 
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Appendix  G.  Assessment  Framework 


G.  1 .  Assessment  F ramework  Methodology 

An  Assessment  Framework  provides  a  structured  methodology  that  facilitates 
information  collection  and  analysis  of  complex  problems.  The  Framework  for  this  study 
of  DoD  IT  business  systems,  specifically  ERPs,  included  identification  of  the  DoD 
enterprise,  operational,  and  financial  environments  and  the  set  of  key  factors  that  affect 
the  successful  development  and  implementation  of  ERPs  within  those  environments.  The 
related  questions  in  the  Framework  also  served  as  the  basis  for  further  research  and  as  an 
outline  for  the  interviews  IDA  conducted. 

The  set  of  key  factors  for  this  Framework  include  the  basic  functions  that  a  high 
performing  organization  must  need  to  perform  in  order  to  oversee,  manage,  and 
implement  an  ERP.  IDA  identified  key  factors  of  governance,  management,  and 
implementation.  Each  of  these  functions  are  addressed  in  the  context  of  the  enterprise, 
operational,  and  financial  environments.  Each  view  has  its  own  characteristics, 
constraints,  and  requirements  related  to  the  key  factors. 

The  following  were  identified  as  key  factors  for  the  DoD  Enterprise  Views  and  for  the 
study  as  shown  in  Table  G-l. 

Enterprise  View 

1.  Commander’s  Intent/Policy,  Vision,  and  Strategy 

2.  Technical  Framework 

3.  Leadership/Adjudication  Framework 

4.  Operations/Programs  View 

5.  Requirements  Management 

6.  Acquisition  Management  (Portfolio  and  Programs) 

7.  Resource  Management 

8.  Financial  View 

9.  Operations 

10.  Reporting/Risk 
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The  Assessment  Framework  with  candidate  questions  is  shown  below: 


Table  G-1.  Assessment  Framework 


Point  of 

View 

Key  Factors 

Questions  to  Assess  Capability  re: 

the  DoD  Business/Financial  IT 

Systems 

Underlying  Questions 

Enterprise 

Commanders 

Intent/ 

Policy,  Vision  & 
Strategy 

What  has  to  happen  and  happen  well  from 

here  on  out?  Is  there  clear  intent? 

Within  the  investments  already  made? 

Is  there  a  general  sense  that  you  are  getting 

what  you  paid  for,  or  have  paid  for  so  far? 

1)  System  Integrator  (SI)  OCI  issues;  2)  Meaningful  Government 

Oversight?;  3)  Impact  of  outsourcing  (to  contractors  for  talent)? 

Is  the  DoD  organized  to  achieve  a  clean  audit 

opinion,  even  as  a  by-product  of  sound 

processes? 

CMO's  role--Where  do  we  go  from  here?  What  do  you  need  it  to  be? 

What  is  your  view  on  Stewardship  -vs.- 

Ownership? 

What  agencies  within  the  DoD  in  particular  and  Federal  (civilian 

agencies)  in  general  embrace  Stewardship  well,  including  a  collective 

sense  of  responsibility  for  better  performance,  management,  and 

reporting? 

Did/Do  the  stakeholders  have  a  say  in  the 

benefits  they  want  from  the  business  ERP's? 

Who  do  you  consider  your  stakeholders? 

Who  would  be  upset  if  you  did  not  get  it  right 

from  an  operations  point  of  view? 

How  closely  connected  is  the  business  mission  to  the  warfighting 

mission? 

Technical 

Framework 

Is  the  DoD  leveraging  the  full  capabilities  of 

the  ERP  investments  already  made?  Given 

what  you  know  now,  do  you  think  a  custom 

solution  would  have  been  better  per:  1 ) 

outcome,  2)  cost,  3)  user  requirements,  4) 

technology  insertions,  5)  leveraging  of  legacy 

systems? 

Is  there  a  fear  that  the  cost  growth  you  have  experienced  in  your  ERP 

program  is  because  the  SI  is  presenting  the  magpie  "shiny  and  new" 

perspective  rather  than  an  approach  to  fully  leverage  what  we  have; 

i.e.,  promoting  wrong  incentives  and  wrong  performance 

measurements? 

What  did  preliminary  pilot  efforts  tell  us?  Were 

the  lessons  actionable? 

The  March  2010  Congressional  Report  on  Defense  Business 

Operations  reported  that  DAI  reduced  obligation  cycle  time  by  97%  and 

financial  reporting  by  75%;  what  is  context  on  this  statistic? 

Did  you  consult  with/share  performance 

information  with  other  services? 

1)  Did  you  have  the  time?,  2)  Were  you  compelled  to  by  obligation 

(jointness)?,  3)  Were  there  any  "ah  ha"  moments  that  you  learned 

outside  your  immediate  agency?,  4)  Was  there  a  requirement  for  you 

(formal/informal)  to  consult  with  agencies  that  were  developing  ERPs?, 

6)  If  you  did  consult,  was  it  with  contractors  or  other  government 

personnel? 

How  seriously  were  legacy  systems 

considered  for  inclusion  into  the  Enterprise 

standard  for  your  agency?  Why/Why  not? 

Examples  of  trade  off  analysis? 

Acquisition  strategy:  How  were  already  made  or  buy-new  decisions 

considered? 
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Point  of 

View 

Key  Factors 

Questions  to  Assess  Capability  re: 

the  DoD  Business/Financial  IT 

Systems 

Underlying  Questions 

When  you  have  a  technical  question  that  is 

strategic  in  nature--who  do  you  go  to? 

Talent:  in  the  government  or  outsourced? 

Can  the  DoD  gov  personnel  make 

adjudication  decisions  independently  without 

help  from  the  SI  or  contractors?  How  are 

those  decisions  promulgated? 

Does  the  Agency  have  the  right  skill  sets  to  provide  competent 

oversight?  Does  the  agency  consider  this  to  be  a:  1)  risk,  2)  priority? 

Do  stakeholders  have  a  voice  in  this  function? 

Who  are  the  stakeholders  for  your  ERP? 

Finance,  Accounting,  Program  Managers,  Logistics,  Acquisition, 

Others? 

Leadership/ 

Adjudication 

Framework 

What  is  the  DoD  formal  authority  to  perform 

this  function  per  CIO,  CFO,  program  owners? 

If  the  authority  is  not  clear,  how  has  this 

impacted  decision-making  concerning  this 

function?  How  should  this  issue  be  addressed 

going  forward? 

Will  CMO  have  a  positive  impact?  What  do  you  need  the  CMO  to  do/ 

to  be  to  ensure  a  positive  impact? 

Does  the  DoD  leadership  have  the  right 

people  in  the  right  positions  with  the  right 

information  to  perform  the  function? 

Will  CMO  have  a  positive  impact? 

Is  the  DoD  organized  appropriately  to  perform 

the  function?  If  not,  what  changes  are  needed 

to  address  the  organizational  issues? 

Will  CMO  have  a  positive  impact? 

Do  you  have  a  sense  of  how  DoD  has  made 

decisions  on  your  ERP?  Have  you  been 

involved  in  those  decisions  or  were  you 

informed  after  the  fact  (if  at  all)?  What 

information  was  used  in  those  decisions  - 

objective  data  that  could  be  supported  or 

opinions/data  that  is  not  supported? 

Confidence  level?  Operations  versus  reporting?  Will  the  CMO  position 

change  this? 

How  are  decisions  communicated  to 

interested  parties?  Do  users  have  a  voice  in 

these  decisions?  Did  the  COTS  approach 

limit  the  voice  of  the  users?  How? 

Who  should  have  a  seat  at  the  table?  Logistics,  Acquisition,  Programs, 

Users,  Accounting,  Finance,  Budget? 

Operations/ 

Programs 

Requirements 

Management 

What  is  the  requirements  collection/vetting 

process  for  this  system?  Estimate  on  a 

percentage  basis  the  number  of  stakeholders 

in  your  agency  consulted  from:  1 )  financials, 

2)  acquisition,  3)  logistics,  4)  program 

managers? 

Inclusive?  How  should  it  be  done?  What  is  preventing  you  from 

conducting  business  this  way? 

Does  the  DoD  have  the  in-house  government 

skills  to  perform  and  provide  oversight? 

Do  we  need  more  technical  skills  on  the  government  side  of  the  table? 

Name  major  barriers  in  the  way.  Veteran  preference  for  SAP  skills? 

Is  the  DoD  organized  appropriately  to  perform 

the  function? 

Piling  on,  or  getting  "it"  done.  Is  there  a  sense  of  a  new  era  in  DoD 

budgets  or  is  the  current  environment  temporary? 
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Point  of 

View 

Key  Factors 

Questions  to  Assess  Capability  re: 

the  DoD  Business/Financial  IT 

Systems 

Underlying  Questions 

Can  the  DoD  make  adjudication  decisions 

with  regard  to  function  or  do  they  abdicate  the 

decision  to  the  SI?  How  are  these  decisions 

on  requirements  communicated? 

Who  is  really  in  charge? 

In  terms  of  outcomes  expected  /desired:  1) 

Who  had  the  loudest  voice,  2)  Who  was 

heard?  3)  Is  there  a  process  to  address 

unfilled  requirements? 

System  Integrators,  Political  Appointees,  Uniforms,  Civilians,  Field 

Personnel,  Accountants,  Program  managers? 

Acquisition 

Management 

(Portfolio  and 
programs) 

What  did  the  contract  (type)  incentivize  the 

contractor  to  do? 

EVMS--  compare  by  the  number  to  by  the  outcome  type  oversight? 

Does  the  DoD  have  the  skill  sets  to  make 

procurement  decisions  with  government 

personnel  only? 

How  comfortable  are  you  with  your  answer? 

Is  the  DoD  organized  to  perform  the  function 

independently? 

Would  the  old  style  OTRR's  (Operational  Test  Readiness  Reviews)  be 

helpful  in  this  regard? 

Can  the  DoD  make  adjudication  decisions 

with  regard  to  function?  Was  there  a  formal 

BCA  completed  for  your  system? 

Were  stakeholders  involved  in  the  both  the 

estimated  cost  and  the  desired  benefits  of  the 

decision  to  move  forward? 

Compelling  need:  1)  Time/Schedule,  2)  Results  -  answering  "the  mail". 

Is  COTS  a  done  deal? 

Financial 

View 

Operations 

If  a  high  performing  federal  finance 

organization  is  defined  as  performing  well  per 

budget  execution,  appropriation  accounting, 

bill  payment,  payroll,  internal  controls,  and 

statutory  financial  reporting,  how  do  you  rank 

your  organization  now?  Does  leveraging  your 

financial  ERP  contribute  to  your  performance 

now  and  how  to  you  project  it  will  contribute 

five  years  from  now? 

A  high  performing  financial  organization  is 

viewed  as  a  trusted  partner  with  program 

managers?  Do  you  agree/disagree?  What 

are  the  risks? 

What  controls  do  you  have  in  place  and  do  you  know  how/if  they  are 

working? 

Is  the  financial  management  system  viewed 

broadly;  i.e.,  in  the  context  that  various 

program  systems  feed  financial  information  to 

the  accounting  system? 
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Point  of 

View 

Key  Factors 

Questions  to  Assess  Capability  re: 

the  DoD  Business/Financial  IT 

Systems 

Underlying  Questions 

Would  you  describe  the  relationship  your 

financial  organization  has  with  the  operations 

and  program  managers  as  a  catalyst,  coach, 

resource,  barrier,  teacher,  other? 

What  changes  have  taken  place  in  the  finance  organization  and  the 

agency?  What  new  risks  have  been  introduced? 

Are  there  legacy  systems  available  to  you 

(your  community)  now  that  you  believe  are 

fully  operational  and  should  be  leveraged 

instead  of  a  net  new  ERP  system;  what  are 

the  benefits/drawbacks  to  the  system  you 

named? 

Reporting  (Risk) 

Improper  Payments 

Debt  Collections 

Top  Down  or  Bottom  Up  in  your  financial 

organization? 

How  is  it  represented  in  the  ERP  and  in  current  legacy  systems? 

Deferred  maintenance  (capital  investment  or 

appropriated  annually?) 

Weapon  Systems,  highways,  bridges,  parks  (Arlington) 

Comment  on  collaboration  between  CIO  and 

CFO  on  enterprise  IT  investments? 

What  is  risk  of  BTA  going  away?  Is  there  a  formal  risk  management 

program? 
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Appendix  H.  Data  Sources 


The  IDA  team  used  multiple  data  sources  and  source  documents  to  ensure  a  holistic 
perspective  was  taken  during  the  analysis.  It  should  be  noted  that  many  of  the  sources 
are  incomplete  and/or  contain  conflicting  infonnation  from  source  to  source.  The  list  of 
data  sources  and  documents  included  the  following: 

Business  Enterprise  Architecture  (BEA) . 

DoD’s  Financial  Improvement  and  Audit  Readiness  (FIAR)  Plan  Status  Reports — 

Reviewed  the  March  2010  and  recently  released  November  2010  reports. 

Integrated  Management  Information  Environment  (IMIE)  was  intended  as  the 
primary  entry  point  for  the  following  data  sources: 

•  Enterprise  Transition  Plan/March  Congressional  Report  to  Congress 

•  BEA  Target  System  Migration  Report 

•  DAMIR  System  Report 

•  DITPR  System  Report 

•  GAO  Reports 

•  OMB  300  Data 

•  Presidential  Budget  Report  FY 1 0  and  FY 1 1 

It  should  be  noted  that  gaining  access  to  IMIE  was  a  very  onerous  process  and  IDA  did 
not  have  adequate  access  for  most  of  the  study  period  of  performance.  On  a  positive 
note,  the  use  of  IMIE  was  critical  in  the  completion  and  validation  of  the  findings  in  this 
study. 

The  IDA  Team  used  the  interviews  and  websites  to  obtain  the  data  sources,  including  the 
Program  Management  Offices  of  the  ERPs  reviewed.  The  data  and  documentation 
analyzed  included: 

•  FY  2010  Enterprise  Transition  Plan 

•  Assessment  of  Defense  Information  Technology  Systems  for  Financial 
Management  conducted  by  the  Corporate  Executive  Board  and  submitted  to 
the  HASC  in  April,  2010 

•  DITPR  System  Reports 

•  GAO  and  DoD  Inspector  General  Reports 

•  OMB  300  Data 
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•  Other  program-specific  documentation,  including— but  not  limited  to— 
architecture  artifacts,  BEA  Compliance  reports,  IRB  approvals,  MAIS 
reports,  and  funding  infonnation. 

Enterprise  Risk  Assessment  Methodology  (ERAM)  -  Reviewed  the  detailed  ERAM 
findings  from  the  various  assessments  of  the  programs  conducted  over  the  last  few  years. 
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Appendix  I.  List  of  Interviewees 


# 

Name  of 

Interviewee 

SES/ 

GO 

Interviewee’s  Organization 

Title  of  Interviewee 

1 

Angwin,  Bob 

-- 

Business  Transformation 
Agency 

DAI  Program  Support 

2 

Argodale,  John  J. 

SES 

Department  of  the  Army 

Deputy  Assistant  Secretary  of  the 
Army  for  Financial  Operations 

3 

Ashworth,  Gary 

-- 

Business  Transformation 
Agency 

Deputy  PEO  Finance 

■ 

Bitz,  Gregory 

— 

Department  of  the  Navy 

Special  Assistant  to  the  Deputy 
Assistant  to  the  Secretary  of  the 
Navy  (Financial  Operations) 

5 

Boddorf,  Gregory 

M. 

SES 

U.S.  Army  Materiel 
Command  (AMC) 

AMC  Resource  Manager  (G-8) 

6 

Boyles,  Stephanie 

S. 

— 

TRICARE  Management 
Activity 

Director,  Enterprise  Architecture, 
Office  of  the  Chief  Financial 

Officer 

1 

Brinkley,  Paul 

SES 

Office  of  the  Secretary  of 
Defense 

Deputy  Under  Secretary  of 

Defense  and  Director  of  the  Task 
Force  for  Business  and  Stability 
Operations 

8 

Brass,  James 

-- 

Army  PEO  EIS 

Cost  Analyst 

9 

Burden,  COL 

Patrick  W. 

-- 

GFEBS  Program  Office 

Project  Manager 

10 

Burton,  Johnny 

Business  Transformation 
Agency 

Chief,  Architecture  and 

Information  Management, 
Enterprise  Planning  and 

Investment 

11 

Carpenter,  Valerie 

- 

Navy  ERP 

Deputy  Program  Manager 

12 

Carter,  Jennifer 

SES 

Navy  ERP 

Program  Manager 

13 

Causey,  Joan  A. 

SES 

Office  of  the  Assistant 
Secretary  of  the  Air  Force 
for  Financial  Management 
and  Comptroller 

Deputy  Assistant  Secretary  for 
Financial  Operations 

14  Chavez,  Anthony  --  TRICARE  Management  Chief,  Management  Control, 

Activity  Office  of  the  Chief  Financial 

Officer 

15  Coleman,  Randy  --  NA  Contractor,  Lead  Systems 

Engineer  -  Business 
Transformation,  Office  of  the 
Deputy  Chief  Management  Officer 

16  Comes,  Scott  A.  SES  Offices  of  the  Secretary  of  Deputy  Director  of  Program 

Defense,  Cost  Evaluation 

Assessment  and  Program 
Evaluation  (OSD  CAPE) 

17  DeLuca,  Chris  --  Business  Transformation  DAI  Deputy  Program  Manager 

Agency 

18  DeVincentis,  Mae  SES  Defense  Logistics  Agency  Vice  Director 

(DLA) 

19  Easton,  Mark  SES  Office  of  the  Linder  Deputy  Chief  Financial  Officer 

Secretary  of  Defense 
(Comptroller) 

20  Engoglia,  Mary  --  GFEBS  Program  Office  GFEBS  Liaison  to  PEO 


21  Fanning,  Eric  K.  SES  Department  of  the  Navy  Deputy  Linder  Secretary  of  the 

Navy,  Business  Operations  & 
Transformation 

22  Fisher,  David  --  TRICARE  Management  Director,  Management  Control 

Activity  and  Financial  Studies,  Office  of 

the  Chief  Financial  Officer 

23  Fisher,  David  M.  SES  Business  Transformation  Director 

Agency 

24  Fisher,  Steven  SES  Office  of  the  Under  Director,  Business  Integration 

Secretary  of  Defense  Office 

(Comptroller) 

25  Flanders,  COL  T.  --  U.S.  Army,  Program  Program  Manger,  Army 

Patrick  Executive  Office,  Enterprise  Systems  Integration 

Enterprise  Information  Program 

Systems 

26  Gaddy,  Zack  SES  Defense  Finance  Director  (retired) 

(retired)  Accounting  Service 
(DFAS) 

27  Gaur,  Prashant  HQE  Business  Transformation  Director,  Enterprise  Integration 

Agency 
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28  Gustafson,  SES  Defense  Finance  Principal  Deputy  Director 

Richard  “Gus”  Accounting  Service 

(DFAS) 

29  McCabe,  Kimberly  SES  Department  of  the  Army  Deputy  Director,  Office  of 

B.  Business  Transformation 

30  Meyer,  Timothy  --  Navy  ERP  Contractor  -  Solutions  Architect 


31  Moran,  BG  GOFO  Expeditionary  Combat  Director 

Kenneth  J.  Support  System  (ECSS) 

32  Morrison,  Diane  --  Business  Transformation  DAI  Program  Manager 

M.  Agency 

33  Muchmore,  Lora  SES  Office  of  the  Deputy  Under  Director,  Business  Enterprise 

Secretary  of  Defense  Integration  Directorate 

(Installations  and 

Environment) 

34  Olgeaty,  Scott  E.  --  Air  Force  Program  Deputy  Director,  Enterprise 

Executive  Office  ,  Financial  Systems  Division 

Electronic  Information 

Systems,  Enterprise 

Financial  Systems  Division 

(AFPEO  E IS/  HIQ  ) 

[DEAMS  Program 
Management  Office] 

35  Omatsola,  Karl  --  Private  Sector  Contractor  support  to  Business 

Transformation  Agency, 
Enterprise  Planning  and 
Investment 

36  Parker,  COL  Brian  --  AFPEO  EIS/HIQ  [DEAMS  Director,  Enterprise  Financial 

A.  Program  Management  Systems  Division 

Office] 

37  Payton,  Hank  --  Private  Sector  Contractor  support  to  Business 

Transformation  Agency, 
Enterprise  Planning  and 
Investment 

38  Poleo,  J.  Anthony  SES  Defense  Logistics  Agency  Chief  Financial  Officer 

“Tony”  (DLA),  Financial 

Operations  (J-8) 

39  Quinn,  Joseph  O.  SES  Office  of  the  Under  Director,  Financial  Improvement 

Secretary  of  Defense  and  Audit  Readiness 

(Comptroller) 

40  Rayman,  Liane  --  GFEBS  Program  Office  Budget  Analyst 
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41 

Rodgers,  Philip 

42 

Rosen,  Ruth 

43 

Seaman,  Keith  E. 

44 

Settle,  Glenna 

45 

Shepherd,  Rich 

46 

Spruill,  Nancy 

47 

Taitano,  Dennis 

48 

Tillotson  III,  David 

49 

Trimble,  Steve 

50 

Trowbridge,  COL 
Jack 

51 

Veit,  Beverly 

52 

Watkins,  James 

53 

Wieczorek,  Erin 
Buechel 

54 

Wise,  Victoria  J. 

55 

Wisnosky,  Dennis 

E. 

Office  of  the  Under 
Secretary  of  Defense  for 
Acquisition,  Technology 
and  Logistics 

Deputy  Director,  Acquisition 
Resources  and  Analysis 

TRICARE  Management 
Activity 

Deputy  Director,  Information 
Management  Business,  Office  of 
the  Chief  Financial  Officer 

Business  Transformation 
Agency 

Defense  Business  System 
Acquisition  Executive 

GFEBS  Program  Office 

Resource  Manager 

GFEBS  Program  Office 

Economic  Advisor 

Office  of  the  Under 
Secretary  of  Defense  for 
Acquisition,  Technology 
and  Logistics 

Director,  Acquisition  Resources 
and  Analysis 

Department  of  the  Navy 

Deputy  Assistant  Secretary  of  the 
Navy  (Financial  Operations) 

Office  of  the  Under 
Secretary  of  the  Air  Force 

Director  of  Business 

Transformation  and  Deputy  Chief 
Management  Officer 

U.S.  Army  Materiel 
Command 

Business  Team  Lead  for  Financial 
Management  on  LMP 

TRICARE  Management 
Activity 

Acting  Chief  Financial  Officer 

Department  of  the  Navy 

Director,  Finance  and  Accounting 
Systems  Division 

Department  of  the  Army 

Director,  Audit  Readiness 

GFEBS  Program  Office 

Congressional  Affairs  Specialist 

U.S.  Army,  Program 
Executive  Office, 

Enterprise  Information 
Systems  (PEO  EIS) 

Special  Projects  Analyst 

Office  of  the  Deputy  Chief 
Management  Officer 

DoD  Business  Mission  Area  Chief 
Technology  Officer  & 

Chief  Architect 
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Appendix  J.  Architectural  Products 


J.l.  Diagram  Report  from  System  Architect 

These  diagrams  were  developed  in  the  course  of  the  study  (HASC  Business  Systems 
Assessment)  to  help  the  IDA  assessment  team  in  the  analysis  of  the  problems/issues  and 
gaps;  to  do  root  cause  analysis  and  to  be  unambiguous 

J.2.  Contents  of  attached  CD 


DOD  BOP  (AV-1)  [0]a  Background  and  Objective 
[ACV  -  Common  Canvas(Free  Form)] 

DOD  BOP  (AV-1)  [0]b  Summary  and  Overview 
[ACV  -  Common  Canvas(Free  Form)] 

DOD  BOP  (OV-1)  [l]a  Overview  of  the  Enterprise  [THE  LINE] 

[ACV  -  Common  Canvas(Free  Form)] 

DOD  BOP  (OV-1)  [4]a  -  Business  Operating  Units  [NONE  AT  THE  TOP] 

[ACV  -  Common  Canvas(Free  Form)] 

DOD  BOP  (OV-1)  [4]b  -  Business  Operating  Units  [OTHER  DEFENSE  AGENCIES] 
[ACV  -  Common  Canvas(Free  Form)] 

DOD  BOP  (OV-1)  [4]cl  -  Business  Operating  Units  [ARMY] 

[ACV  -  Common  Canvas(Free  Form)] 

DOD  BOP  (OV-1)  [4]c2  -  Business  Operating  Units  [AF] 

[ACV  -  Common  Canvas(Free  Form)] 

DOD  BOP  (OV-1)  [4]c3  -  Business  Operating  Units  [NAVY] 

[ACV  -  Common  Canvas(Free  Form)] 

DOD  BOP  (OV-1)  [4]c4  -  Business  Operating  Units  [MC] 

[ACV  -  Common  Canvas(Free  Form)] 

DOD  BOP  (OV-1)  [4]d  -  Business  Operating  Units  [COMBATANT  COMMANDS] 
[ACV  -  Common  Canvas(Free  Form)] 

DOD  BOP  (OV-1)  [4]e  -  Business  Operating  Units  [DEPLOYED  FORCES] 

[ACV  -  Common  Canvas(Free  Form)] 
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DOD  BOP  (OV-3)  Capability  Map  [ALL  LEVELS  OF  THE  ENTERPRISE] 

[ACV-Business] 

DOD  BOP  (OV-6c)  Structure  where  there  was  none  [OV-06c  Work  Flow] 

DOD  BOP  (OV-7)  [1]  Triple  Stores  [PEOPLE,  PROCESSES,  TOOLS]  [OV-07a  Class  Data] 
DOD  BOP  (OV-7)  [9]  Systems  Portfolio  and  Audit-ability  [OV-07e  Relational  Data  (IDEF)] 


J-2 


Appendix  K.  Acronyms 


AF 

AFB 

AFR 

AIS 

AMR 

APR 

APVM 

BCL 

BCLP 

BEA 

BEIS 

BEIS  FoS 
BEP 

BICARSA 

BMMP 

BOU 

BPA 

BPML 

BPMN 

BPR 

BTA 

CAC 

CAD 

CAM 

CFO 

CJCSI 

CMO 

COTS 

CSC 

DAI 

DAMIR 

DCMO 

DEAMS 

DFARS 

DFPS 

DHS 

DIMHRS 

DISA 

DITPR 


Air  Force 

Air  Force  Base 

Agency  Financial  Report 

Automated  Information  Systems 

Annual  Management  Report 

Annual  Performance  Report 

Accounting  Prevalidation  Module 

Business  Capability  Lifecycle 

Business  Capability  Lifecycle  Process 

Business  Enterprise  Architecture 

Business  Enterprise  Information  System 

Business  Enterprise  Information  Services  Family  of  Systems 

Business  Enterprise  Priority 

Billing,  Inventory  Control,  Accounts  Receivable,  &  Sales  Analysis 

Business  Management  Modernization  Program 

Business  Operating  Units 

Blanket  Purchase  Agreement 

Business  Process  Modeling  Language 

Business  Process  Modeling  Notation 

Business  Process  Re-engineering 

Business  Transformation  Agency 

Common  Architecture  Capability 
Computer-Aided  Design 
Computer-Aided  Manufacturing 
Chief  Financial  Officer 

Chairman  of  the  Joint  Chiefs  of  Staff  Instruction 
Chief  Management  Officer 
Commercial-off-the-shelf 
Computer  Science  Corporation 

Defense  Agency  Imitative 

Defense  Acquisition  Management  and  Information  Retrieval 

Deputy  Chief  Management  Officer 

Defense  Enterprise  Accounting  and  Management  System 

Defense  Federal  Acquisition  Regulation  System 

Defense  Force  Public  Security 

Department  of  Flomeland 

Defense  Integrated  Military  Fluman  Resources  System 
Defense  Information  Systems  Agency 
DoD  IT  Portfolio  Repository 
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DoD 

DoDAF 

DoDI 

DOTMLPF 
DUSD  (BT) 


Department  of  Defense 
DoD  Architecture  Framework 
Department  of  Defense  Instruction 

Doctrine,  organization,  training,  materiel,  leadership  and  education,  personnel 
and  facilities 
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